home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-newnan-isomib-internet-02.txt
< prev
next >
Wrap
Text File
|
1993-06-07
|
211KB
|
6,772 lines
INTERNET DRAFT Expires November 29, 1993
ISO/CCITT and Internet Management Coexistence (IIMC):
Translation of ISO/CCITT GDMO MIBs to Internet MIBs
(IIMCOMIBTRANS)
Draft 2
May 26, 1993
Owen Newnan (Editor)
U S WEST Advanced Technologies
4001 Discovery Drive, Suite 190
Boulder, Colorado 80303
onewnan@advtech.uswest.com
Status of this Memo
This document provides information to the network and systems
management community. This document is intended as a
contribution to ongoing work in the area of multi-protocol
management coexistence and interworking. This document is part
of a package; see also [IIMCIMIBTRANS] [IIMCMIB-II] [IIMCPROXY]
and [IIMCSEC]. Distribution of this document is unlimited.
Comments should be sent to the Network Management Forum IIMC
working group (iimc@thumper.bellcore.com).
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a ``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, munnari.oz.au to learn the
current status of any Internet Draft.
Newnan Expires November 29, 1993 Page i
Draft Translation of ISO/CCITT MIBs to Internet MIBs5/26/93
Abstract
This document provides heuristic procedures that translate
managed object specifications from ISO/CCITT Guidelines for
Definition of Managed Object (GDMO) templates to Internet MIB
macros. Currently, some market segments demand SNMP for
customer network management, while others require the ISO/CCITT
Common Management Information Protocol (CMIP). The approach
defined in this document accommodates both, protecting
investment already made in management information specifications
and minimizing cost to implement a second protocol where the
market requires. This translation is designed to: lose as
little functionality as possible in translation; minimize need
for human involvement during translation; minimize the cost of
dual protocol and proxy-based implementations; and support
generic network models which span many computer platforms and
network elements. This document is intended to encourage
standardization of such an approach and promote consistent usage
of MIB definitions, independent of protocol.
Table of Contents
Status of this Memo......................................i
Abstract.................................................ii
Table of Contents........................................ii
Revision History.........................................iv
1 Introduction..........................................1
1.1 Problem Statement...................................1
1.2 Overview of IIMC....................................2
1.3 MIB Translation Procedures..........................2
1.4 Native Management Model.............................3
1.5 Proxy Management Model..............................5
1.6 Scope of this Document..............................6
1.7 Terms and Conventions...............................7
2. SNMPv1 Translation Procedures.........................9
2.1 Relationship to RFC1212..............................9
2.2 Mapping of Managed Object Classes and Attributes.....10
2.3 Mapping to the SYNTAX clause.........................18
2.4 Generation of Internet MIB Identifiers...............22
2.5 Mapping to the ACCESS clause.........................27
2.6 Mapping to the STATUS clause.........................27
2.7 Mapping to the DESCRIPTION clause....................27
2.8 Mapping to the REFERENCE clause......................28
2.9 Mapping to the INDEX clause..........................28
2.10 Mapping to the DEFVAL clause........................28
2.11 Translation of Actions..............................29
2.12 Translation of Notifications........................30
2.13 Translation of Delete Operations....................33
2.14 Translation of Create Operations....................34
3. Constraints on SNMPv1 Protocol Usage..................38
4. SNMPv2 Translation Procedures.........................39
4.1 General Approach.....................................39
Newnan Expires November 29, 1993 Page ii
Draft Translation of ISO/CCITT MIBs to Internet MIBs5/26/93
4.2 Object Definitions ...................................40
4.3 Trap Definitions .....................................43
5. Constraints on SNMPv2 Protocol Usage ..................44
5.1 Approach .........................................44
5.2 Discussion .........................................45
6. Summary ...............................................45
7. Acknowledgments .......................................46
References ...............................................48
Appendix A (Informative): Abridged Example ...............50
A.1 Input ISO/CCITT Management Information Base ..........50
A.2 Output SNMPv1 Management Information Base ............54
A.3 Output SNMPv2 Management Information Base ............64
Appendix B (Normative): Definition of Management
Information ..............................................76
B.1 Notes on ISO/CCITT DMI Translation ...................76
B.2 SNMPv1 Translation of DMI ............................80
B.3 SNMPv2 Translation of DMI ............................90
Appendix C (Normative): Support Objects For Use With
Translated MIBs ..........................................101
Newnan Expires November 29, 1993 Page iii
Draft Translation of ISO/CCITT MIBs to Internet MIBs5/26/93
Revision History
Draft 0 - October 9, 1992
Initial draft of this document.
Draft 1 - March 26, 1993
Previous draft of this document (replaced Draft 0).
Draft 1 - May 26, 1993
Current draft of this document (replaces Draft 1).
Major Changes Since Last Revision
1. Removed convergence MIB, and revised structure and content of
the conceptual rows generated in translation:
- Replaced StatusDelete objects with SNMPv2 RowStatus.
- Moved containment information from the compatibility MIB
into the class object groups.
- Assigned column OIDs sequentially, beginning with one.
- Revised name translation and table generation procedures.
2. Clarified enumerated usage.
3. Restructured document to accommodate SNMPv2:
- Revised requirements to minimize differences between v1 and
v2 mappings.
- Redefined class entry instance to class InstancePointer,
reflecting SNMPv2 InstancePointer conventions.
- Added a table showing how common constructs (types and
conventions) of the SNMPv2 are mapped to/from OSI usage.
Where practical, adjusted the v1 output to anticipate/align
with v2 usage.
- Specified read-create for generated table entries.
- Reflected ranges and permitted values from the input MIB.
- Added discussion of constraints on v2 protocol usage
- Both annexes revised with subsections providing SNMP v2
MIBs.
4. Clarified SET OF CHOICE usage.
5. Incorporated new introduction and clarified the distinction
between MIB translation and supporting conventions,
constraints and objects.
6. Better aligned style and use of terms with other IIMC
documents (arcs vs. legs, labels versus identifiers) and NMF
usage (normative and informative appendices).
7. Updated SNMPv2 references to the final RFCs.
8. Changed auto-registry and made other adjustments to
accommodate common SNMP parsers.
Newnan Expires November 29, 1993 Page iv
Draft Translation of ISO/CCITT MIBs to Internet MIBs5/26/93
Outstanding Issues
1. Further investigation to determine whether a more
comprehensive and deterministic mapping of notifications is
feasible and appropriate. Concurrently, a complete and
normative translation of DMI [ISO10165-2] should be attempted
to provide a more comprehensive example translated MIB.
2. Conformance and compliance, and registry of translated MIBs,
are yet to be addressed. Use of the DESCRIPTION clause to
define textual conventions and additional constraints should
be considered.
3. The mapping for ANY and CHOICE syntaxes requires further
study; comments are solicited during review.
Newnan Expires November 29, 1993 Page v
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
1 Introduction
This section provides an overview of ISO/CCITT and Internet
Management Coexistence (IIMC) activities, insight into the
problem being addressed by IIMC, and a brief introduction to
the strategy adopted by IIMC: use of translated MIBs in either
a proxy or native implementation. The section concludes by
describing the scope of this document, and terms and
conventions used by this document.
1.1 Problem Statement
The need for enterprise network management has been addressed
by development of network management standards within various
communities, most notably the ISO/CCITT and Internet
communities.
- The ISO/CCITT community developed the Common Management
Information Protocol (CMIP) [ISO9596-1], and related
SMI documents [ISO10165-1,2,4].
- The Internet community developed the Simple Network
Management Protocol (SNMP) [RFC1157], and its
successor, SNMPv2 [RFC1448]. The Internet SMI is
defined in [RFC1155] and [RFC1442].
These standards share a nearly common management model, but
diverge due to differing management philosophies. Although
functionally similar, the Internet and ISO/CCITT protocols and
SMIs differ in terms of their complexity and specific
operations. Business requirements for end-to-end enterprise
management include the need to integrate the management of
components accessed by ISO/CCITT management, Internet
management, and proprietary management mechanisms in a manner
which presents a unified view of the network, despite protocol
and SMI differences.
For example, many telecommunications and computer vendors,
represented by organizations such as the Network Management
Forum (NMF), and the U.S. government, as specified in the
Government Network Management Profile (GNMP), have based their
enterprise management model on the ISO/CCITT management model.
These organizations are particularly interested in integrated
management of devices that use the Internet management. This
interest is primarily due to the widespread commercial
implementation and use of such devices, especially devices
that use the Internet TCP/IP protocol suite.
Newnan Expires November 29, 1993 Page 1
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
1.2 Overview of IIMC
This document is part of a package of ISO/CCITT and Internet
Management Coexistence (IIMC) drafts. Documents included in
this package are:
[IIMCIMIBTRANS] Translation of Internet MIBs to ISO/CCITT
GDMO MIBs
[IIMCOMIBTRANS] Translation of ISO/CCITT GDMO MIBs to
Internet MIBs
[IIMCMIB-II] Translation of Internet MIB-II (RFC1213)
to ISO/CCITT GDMO MIB
[IIMCPROXY] ISO/CCITT to Internet Management Proxy
[IIMCSEC] ISO/CCITT to Internet Management Security
These documents together comprise a package aimed at
integrating ISO/CCITT-based and Internet-based management
systems. These documents represent coexistence and
interworking efforts underway within the IIMC working group,
chartered under the auspices of the Network Management Forum
Architecture Integration ISO/Internet (AIII) technical team.
The IIMC intends to address the problem that end-to-end
management requires an integrated, unified view of the managed
network, despite differences in management protocol and
information structure. Integrated management can be
facilitated by the development of "proxy" mechanisms which
translate between functionally equivalent service, protocol,
and SMI differences to create this unified view. MIB
translation procedures can be used to support proxy
management, as well as to take advantage of existing MIB
definition and avoid duplication of effort. In this way,
commercial investment in both ISO/CCITT and Internet-based
management technologies can be preserved through deployment of
common methods and tools which support integration.
This overall strategy was outlined in a joint publication
developed by the NM Forum and X/Open entitled "ISO/CCITT and
Internet Management: Coexistence and Interworking Strategy"
[NMFTR107]. The documents included in the IIMC package are
the next level of detailed specifications which implement
several of the methodologies identified in the strategy.
1.3 MIB Translation Procedures
The foundation of IIMC is provided by a pair of Management
Information Base (MIB) translation procedures.
Newnan Expires November 29, 1993 Page 2
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
- [IIMCIMIBTRANS] specifies translation procedures for
converting MIBs from Internet MIB macro format into
ISO/CCITT GDMO template format.
- [IIMCOMIBTRANS] specifies translation procedures for
converting MIBs from ISO/CCITT GDMO template format
into Internet MIB macro format.
The IIMC approach is to specify direct translation procedures
which yield a pair of functionally-equivalent MIBs, as shown
in the following figure.
+----------------+ +--------------------+ +----------------+
| Internet MIB | | MIB Translation | | GDMO MIB |
| | | Procedures | | |
| Format = | | Specified By | | Format = |
| [RFC1212] & |---->| [IIMCIMIBTRANS] or |---->| [ISO10165-1] & |
| [RFC1442] |<----| [IIMCOMIBTRANS] |<----| [ISO10165-4] |
+----------------+ +--------------------+ +----------------+
MIBs translated by these procedures may be used to take
advantage of existing MIB definitions when business needs
require deployment in a different management environment.
Translated MIBs may also be used to provide uniformity when
multiple management environments are supported by a single
system (e.g., dual stack managers). Finally, IIMC MIB
translation procedures may be used to support service
emulation by a proxy.
1.4 Native Management Model
The basic model for ISO/CCITT and Internet management is
illustrated in the following diagram.
Newnan Expires November 29, 1993 Page 3
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Manager Agent
+-----------------------+ +----------------------+
|+---------------------+| |+-------------------+ |
|| Management || || Managed | |
|| Applications || || Resources | |
|+---------------------+| |+-------------------+ |
| | | | | |
| | | | | |
|+-----------+---------+| |+----------+---------+|
|| Manager | MIB || || Agent | MIB ||
|+-----------+---------+| |+----------+---------+|
| | | | | |
| | Management | | | Management |
| | Services | | | Services |
+-----------------------+ +----------------------+
| Management Protocol | | Management Protocol |
+-----------------------+ +----------------------+
^ ^
| |
+------------------------------------+
Protocol Messages
Within IIMC documents, this model is referred to as the
"native" management model. MIBs translated using IIMC
procedures can be used by "native" agent implementations. For
example, an ISO/CCITT agent can make visible TCP/IP managed
resources using the translated GDMO version of the Internet
MIB-II [RFC1213] specified by [IIMCMIB-II]. Dual-stack
managers or agents may also be implemented which support both
the original MIB and the translated MIB generated using IIMC-
specified procedures.
Newnan Expires November 29, 1993 Page 4
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
1.5 Proxy Management Model
The basic model for ISO/CCITT to Internet proxy management is
illustrated in the following diagram. This proxy is specified
by [IIMCPROXY]. A similar approach could also be taken to
specify an Internet to ISO/CCITT proxy, although no such IIMC
document is currently specified.
Manager Proxy Agent
+-----------------------+ +---------------------+ +----------------------+
|+---------------------+| |+------+ +----------+| |+-------------------+ |
|| Management || || GDMO | | Internet || || Managed | |
|| Applications || || MIB | | MIB || || Resources | |
|+---------------------+| |+------+ +----------+| |+-------------------+ |
| | | |+-------------------+| | | |
| | | || Service || | | |
| | | || Emulation || | | |
| | | ||(scoping) || | | |
| | | || (filtering) || | | |
| | || (operations)|| | | |
|+-----------+---------+| |+-------------------+| |+----------+---------+|
|| ISO/CCITT | GDMO || || Protocols Mapping || || Internet | Internet||
|| Manager | MIB || || CMIS |...| SNMP || || Agent | MIB ||
|+-----------+---------+| |+-------------------+| |+----------+---------+|
| | | | |CMIS | | | | |
| | CMIS Services | | |Services | | | | SNMP "Services" |
| | | | | | | | | |
| | | | | SNMP| | | | |
| | | | | "Services"| | | | |
+-----------------------+ +---------------------+ +----------------------+
| CMIP | | CMIP | SNMP | | SNMP |
+-----------------------+ +---------------------+ +----------------------+
^ ^ ^ ^
| | | |
+---------------------+ +-------------------+
CMIP Messages SNMP Messages
This ISO/CCITT to Internet proxy provides emulation of CMIS
services by mapping to the corresponding SNMP message(s)
necessary to carry out the service request. The service
emulation allows management of Internet objects by an
ISO/CCITT manager. The left hand side of the proxy behaves
like an ISO/CCITT agent, communicating with the ISO/CCITT
manager using CMIP protocols. The right hand side of the
proxy behaves like an Internet manager, communicating with the
Internet agent using SNMP protocols.
The proxy relies on the existence of a pair of directly-
related MIB definitions, where the Internet MIB has been
translated into ISO/CCITT GDMO using the procedures specified
in [IIMCIMIBTRANS]. The proxy uses these MIB definitions and
Newnan Expires November 29, 1993 Page 5
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
rules to provide run-time translation of management
information carried in service requests and responses.
The proxy is designed with a specified interface between the
proxy and the underlying protocol stacks, and so deals
primarily in terms of CMIS services and SNMP "services". The
proxy emulates services such as CMIS scoping and filtering,
processing of CMIS operations, and forwarding/logging of CMIS
notifications by performing a mapping process which must be
tailored for each protocol (for example, SNMPv1 and SNMPv2 are
variants of the same protocol mapping process).
1.6 Scope of this Document
This document (IIMCOMIBTRANS) specifies an heuristic method to
translate from ISO/CCITT GDMO MIB specifications to Internet
SNMPv1 and SNMPv2 MIB macro specifications. The method is
intended to meet six objectives:
- Lose as little functionality as possible in translation.
- Minimize need for human involvement in translation.
- Minimize cost to implement multi-stack (e.g., CMIP, SNMPv1
and SNMPv2) and proxy-based applications.
- Support an end-to-end view (e.g., Generic Network Model) of
distributed information resources that span many computing
platforms and network elements.
- Support translation to both SNMPv1 and SNMPv2 while
minimizing differences between the two mappings. An
important corollary is to generate objects and
traps/notifications that are syntactically and semantically
equivalent and can therefore be registered the same.
- Within constraints of the other objectives, generate MIBs
that are as consistent with customary Internet usage as
possible. In particular, these should be compatible with
common SNMP parsers.
While entirely mechanized translation from an ISO/CCITT GDMO
MIB to an Internet MIB is not always possible, the intent is
to mechanize the process as much as possible and supply
reasonable defaults that may be tempered by human judgment.
This specification provides core methodology such that a GDMO
template specification can be translated to Internet MIB macro
notation. It thus supports native mode implementations.
Proxy implementations are beyond the scope of this document.
However, in the longer term, MIBs translated using this method
Newnan Expires November 29, 1993 Page 6
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
could be used in conjunction with a proxy architecture to
enable interworking between ISO/CCITT managers and Internet
agents.
The body of this document has six sections:
- Introduction
- SNMPv1 Translation Procedures
- Constraints on SNMPv1 Protocol Usage
- SNMPv2 Translation Procedures
- Constraints on SNMPv2 Protocol Usage
- Summary
Sample inputs and translated outputs (both normative and
informative) are provided in appendices. Appendix C also
provides some supporting Internet macro object specifications
to assist in MIB translation and implementation.
Two outstanding issues have been identified that are outside
the scope of the present version of this document, but may be
addressed in future versions:
- definition of a Proxy for translated ISO/CCITT GDMO MIBs,
and
- definition of "Pragmas" to document human overrides to
algorithmic translation in a systematic and machine readable
form. Among other things, this might facilitate generation
of proxies.
This specification assumes existence of appropriate mechanisms
and procedures for registry of translated objects. What those
procedures might be and where such objects should be
registered, however, are beyond the scope of this document.
1.7 Terms and Conventions
This document assumes the reader is familiar with the concepts
and vocabularies of Internet and ISO/CCITT management. In
cases where there might be confusion between the two, words
such as "ISO/CCITT", "GDMO" and "Internet" are inserted to
avoid ambiguity.
The term "SNMP" is used throughout this document generically
to indicate both the SNMPv1 and SNMPv2 frameworks, unless a
distinction needs to be made. The terms SNMPv1 and SNMPv2 are
used to refer to the respective frameworks specifically.
Formal language constructs from the various MIB notations
(ATTRIBUTE, OBJECT-TYPE, SYNTAX, etc.) are used verbatim in
this text. Plurals of such keywords ending in upper case are
expressed by appending "s" or "es" (e.g., NOTIFICATIONs) while
Newnan Expires November 29, 1993 Page 7
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
those ending in lower case are suffixed with "'s" (e.g.,
TruthValue's).
The terms "class" and "attribute" when expressed in lower case
are generic, referring either to ISO/CCITT MANAGED OBJECT
CLASSes and ATTRIBUTEs (respectively) or their translated
Internet MIB counterparts.
The term "arc" means a single level of branching within an
Abstract Syntax Notation One (ASN.1) registration tree.
The terms "enumerate" and "explode" are used synonymously to
describe the process of translating ATTRIBUTEs and their
values to OBJECT-TYPE macros.
A "registry family" is defined to be a set of ASN.1 OBJECT
IDENTIFIER arcs and nodes sharing a common immediate parent.
Identifiers of Internet MIB macro constructs are referred to
as "labels".
The following notation is used to specify mapping rules:
- Symbols enclosed in quotes are literals.
- Symbols enclosed in angle brackets ("<>") are variables that
have different string values depending on instance or
context. Figure 3 describes the variables.
- Double upended bars ("||") signify the concatenation
operator. For this operator, literals are concatenated
without modification. When concatenating a variable
however, its first character of its value string is promoted
to upper case. Strings are concatenated without intervening
punctuation or white space to arrive at the resulting label.
Internet conventions are observed throughout the text.
Customary SNMP types and textual conventions [RFC1443] are
produced in the translated output whenever there is a
straightforward mapping. Such types and conventions are most
developed in SNMPv2. Considering the need to minimize
differences between SNMPv1 and SNMPv2 outputs, the SNMPv1
outputs are designed to anticipated SNMPv2 usage. The
following table summarizes the SNMPv2 types and conventions
mapped to (in alphabetic order of SNMPv2 construct).
Newnan Expires November 29, 1993 Page 8
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
-------------------------------+-----------------------------
ISO Construct | SNMPv2 Types And Conventions
-------------------------------+-----------------------------
counter ATTRIBUTE | Counter32 & 64 Types
GeneralizedTime & UTCTime | DateAndTime Convention
IA5String, NumericString, | DisplayString Convention
PrintableString, VisibleString |
GraphicString | GraphicString (see below)
gauge ATTRIBUTE | Gauge32 Type
ObjectInstance or DN | InstancePointer Convention
INTEGER Type | Integer32 or UInteger32
Create/Delete operations and | RowStatus Convention
administrative state |
BOOLEAN type | TruthValue Convention
-------------------------------+-----------------------------
All of these are native constructs for SNMPv2, except for
GraphicString (which is an SNMPv2 textual convention defined
by this specification - refer to Appendix C.2), corresponding
to the commonly used OSI type of the same name. Usage of all
these constructs is further developed in the sections below.
2. SNMPv1 Translation Procedures
2.1 Relationship to RFC1212
While translation per se has not previously been widely
investigated, [RFC1212] does provide advice for adopting MIB
objects from ISO/CCITT GDMO to Internet MIB macros. RFC 1212
advises a minimalistic approach to MIB specification,
discouraging carryover of the complexities often found in
ISO/CCITT GDMO specifications. Thus, it does not so much tell
how to translate a MIB as provide advice for borrowing
elements of a ISO/CCITT GDMO specification and constructing a
MIB more in keeping with Internet philosophy.
The translation procedure provided here seeks instead to
provide as faithful a translation as possible, in order to
support the objectives identified in section 1.2 above.
As applicable, the subsections are divided into one or more of
the following parts.
- Relevant advice quoted verbatim from RFC1212. Beware that
the entire RFC is not quoted here. The reader is referred
to the source for complete text.
- Additional constraints are identified to allow as
comprehensive and mechanizable an approach as possible.
- Discussion of the translation procedure is provided as
guidance to the reader.
Newnan Expires November 29, 1993 Page 9
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
2.2 Mapping of Managed Object Classes and Attributes
2.2.1 RFC 1212 Advice
... The next step is to categorize the objects into groups.
For experimental MIBs, optional objects are permitted.
However, when a MIB module is placed in the Internet-standard
space, these optional objects are either removed, or placed in
an optional group, which, if implemented, all objects in the
group must be implemented. For the first pass, it is wisest
to simply ignore any optional objects in the original MIB:
experience shows it is better to define a core MIB module
first, containing only essential objects; later, if experience
demands, other objects can be added.
It must be emphasized that groups are "units of conformance"
within a MIB: everything in a group is "mandatory" and
implementations do either whole groups or none.
Next for each managed object class, determine whether there
can exist multiple instances of that managed object class. If
not, then for each of its attributes, use the OBJECT-TYPE
macro to make an equivalent definition.
Otherwise, if multiple instances of the managed object class
can exist, then define a conceptual table having conceptual
rows each containing a columnar object for each of the managed
object class's attributes. If the managed object class is
contained within the containment tree of another managed
object class, then the assignment of an object type is
normally required for each of the "distinguished attributes"
of the containing managed object class. If they do not
already exist within the MIB module, then they can be added
via the definition of additional columnar objects in the
conceptual row corresponding to the contained managed object
class.
In defining a conceptual row, it is useful to consider the
optimization of network management operations that will act
upon its columnar objects. In particular, it is wisest to
avoid defining more columnar objects within a conceptual row,
which can fit in a single PDU. As a rule of thumb, a
conceptual row should contain no more than approximately 20
objects. Similarly, or as a way to abide by the "20 object
guideline", columnar objects should be grouped into tables
according to the expected grouping of network management
operations upon them. As such, the content of conceptual rows
should reflect typical access scenarios, e.g., they should be
organized along functional lines such as one row for
statistics and another row for parameters, or along usage
Newnan Expires November 29, 1993 Page 10
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
lines such as commonly-needed objects versus rarely-needed
objects.
On the other hand, the definition of conceptual rows where the
number of columnar objects used as indexes outnumbers the
number used to hold information, should also be avoided. In
particular, the splitting of a managed object class's
attributes into many conceptual tables should not be used as a
way to obtain the same degree of flexibility/complexity as is
often found in MIBs with a myriad of optionality.
2.2.2 Additional Constraints
The discussion that follows has six parts.
1. Framework (which introduces the general approach and
such notions as class, side and child tables)
2. Registration of Modules and Tables
3. Structure of Class Tables
4. Structure of Side Tables
5. Structure of Child Tables
6. Enumeration of Attribute Values
2.2.2.1 Framework
The framework that follows establishes the general approach to
translation. It also introduces associated vocabulary used
throughout the remainder of the text.
Every MANAGED OBJECT CLASS input maps to a corresponding
object group, the "class group." Each class group consists
entirely of Internet MIB tables that are logically linked to
each other, namely,
- A "class table" that corresponds to the class as a whole.
It contains objects representing scalar ATTRIBUTEs and
additional objects that reflect status and containment
relationships.
- Zero or more "side tables" to accommodate multiply occurring
attribute values. Subsection 2.3 below provides instruction
about how side tables are generated.
- A "child table" that lists subordinate managed objects as
mapped into SNMP macros.
For each managed object mapped, there is a single entry in the
corresponding class table, the "class entry." Associated with
this are zero or more "side entries" and "child entries",
associated conceptual rows within the class group. A "class
instance" is a class entry together with any associated side
and child entries.
Newnan Expires November 29, 1993 Page 11
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
A class InstancePointer is an OBJECT IDENTIFIER that
discriminates (points to) a class instance. It conforms to
the SNMPv2 InstancePointer textual convention. Specifically,
it points to the first column of the class entry.
The class InstancePointer is used in lieu of the OSI
Distinguished Name (DN). It is analogous to the DN in that it
names a particular instance of a managed object class, also
supplying the type of the object pointed to. However, it is
more compact and less mnemonic than the DN.
2.2.2.2 Registration of Modules and Tables
Begin translation of a registry family of MANAGED OBJECT CLASS
specifications by allocating the root of a registry subtree to
contain the translated objects, the "output subtree."
Note: Assignment of naming prefixes and registry subtrees
are required activities, however, procedures for these
are outside the scope of this document.
Assign a brief naming prefix to assist in labeling the
contents of a corresponding ASN.1 module to be generated.
Define an OBJECT IDENTIFIER of the form
<naming prefix> || " OBJECT IDENTIFIER ::= "
|| <output subtree>
Register the ASN.1 module that is produced as:
"{ " || <output subtree> || " 0 1 }"
Name the resulting module:
"MIB" || <naming prefix> || "SNMPv1",
e.g., MIBt1taSNMPv1.
For each MANAGED OBJECT CLASS of the input registry family,
define a corresponding Internet MIB object group -- the class
group. Assign an arc to each, keeping the same relative arc
number in the output registry family as assigned to its
equivalent MANAGED OBJECT CLASS in the input (ISO/CCITT GDMO)
registry. Avoid registration of ISO/CCITT objects under arc
zero(0) by substituting the value 16,384.
Assign arcs to the various tables of a class group.
- The class table registry is the same as that of the class
group arc.
Newnan Expires November 29, 1993 Page 12
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
- Assign arcs for side tables in ascending order beneath the
class group arc beginning with arc number two.
- Assign the child table its own arc underneath the class
group, its arc number immediately following that of the
highest numbered side table.
Note: Since all ATTRIBUTEs expand into class tables or
side tables, class groups generated by the algorithm
never contain scalar values.
For each table in the class group, define a table entry object
and syntax consistent with RFC 1212 usage for table entries
(naming of objects and entries is addressed below).
2.2.2.3 Structure of Class Tables
For the entries of a class table, begin by allocating the
following conceptual columns and associated arcs.
Reserve arc 0 beneath the class entry arc per the Internet
Structure of Management Information (SMI).
Assign arc 1 to the "class entry index," an INTEGER valued
object that provides the unique index of a class entry. This
may be an arbitrary value without particular meaning. The
class InstancePointer is arrived at by concatenating:
- The OBJECT IDENTIFIER of the class entry.
- The value 1 (arc number for the class entry index)
- The value of the class entry index for the instance in
question. This index is not-accessible.
Note: Here, "concatenating" means arriving at a simple
combined sequence of arc values, without repeat counts or
nesting.
Also Note: The class InstancePointer value is used in the
translated MIB in lieu of the OSI Distinguished Name's
and ObjectInstance's that represent relationships between
managed objects. As discussed in section 2.2.3, no
direct translation of Distinguished Names is provide.
Assign arcs 2 through <n+1> sequentially to the <n> conceptual
columns that correspond to attribute values.
Note: instructions for mapping of ATTRIBUTE syntax to
conceptual columns of the class and side tables are provided
in subsection 2.3.
Newnan Expires November 29, 1993 Page 13
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Assign arc <n+2> to the parent object, a class InstancePointer
that points to the superior (parent) class entry.
Assign arc <n+3> to the NameBinding object, which holds an
OBJECT IDENTIFIER that distinguishes the NAME BINDING in
effect for the class instance.
Assign arc <n+4> to the RowStatus object, which conforms to a
subset of the SNMPv2 RowStatus textual convention, allowing
creation and deletion of class instances.
2.2.2.4 Structure of Side Tables
Side entries have similar structure.
Reserve arc 0 beneath the class entry arc per the Internet
Structure of Management Information (SMI).
Assign arc 1 to the "class index," an INTEGER valued object
that provides the same value as the corresponding class entry
index. This may be an arbitrary value without particular
meaning and is not-accessible.
Assign arcs 2 through <m+1> sequentially to the <m> "value
indexes" that collectively qualify the class index to uniquely
identify a particular entry in the side table. These also are
INTEGER valued objects which may have arbitrary values and are
not-accessible.
Assign arcs <m+2> through <m+n+1> sequentially to the <n>
conceptual columns that correspond to attribute values.
Assign arc <m+n+2> to the RowStatus object, which conforms to
a subset of the SNMPv2 RowStatus textual convention, allowing
creation and deletion of values for multivalued attribute
syntax.
2.2.2.5 Structure of Child Tables
Assign child tables entries the following structure.
Reserve arc 0 beneath the class entry arc per the Internet
Structure of Management Information (SMI).
Assign arc 1 to the class index, a not-accessible OBJECT
IDENTIFIER valued object that identifies the class of child
for which pointers are desired.
Newnan Expires November 29, 1993 Page 14
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Assign arc 2 to the value index, a not-accessible INTEGER
valued object that identifies the instance of child within its
class
Assign arc 3 to the CHILD OBJECT, a read-only OBJECT
IDENTIFIER valued object that provides an InstancePointer to a
particular subordinate class entry, i.e., an object contained
beneath the class instance in question.
2.2.2.6 Enumeration of Attribute Values
In this section, the reader may wish to refer to Figures 1 and
2, which illustrate the input and output subtrees of the
sample translated MIB (Appendix A). Note that, for this
example, the Trouble Administration module is rooted beneath
an (optional) version arc, to facilitate future releases.
trGNM(1 2 840 10015 0)
|
+-------------------+----------------------+
| |
trMObjectClass(3) trAttribute(7)
| |
| +-----+-----+-----+
troubleReport(5) | | | |
accessTime .... cancel
LocationList(2) RequestedBy
Manager(12)
Figure 1. Sample Input Registration Tree
All else being equal, enumerate ATTRIBUTEs based upon a left-
to-right scanning of the input ISO/CCITT GDMO specification.
ATTRIBUTEs and their values may be enumerated multiple times
in the course of translating a specification, once for every
template in which they are referenced. For example, if an
attribute is included in the PACKAGEs of two MANAGED OBJECT
CLASSes, it will be enumerated twice in the output: once for
each class group.
Enumerate ATTRIBUTEs and their values in the same sequence as
declared in a PACKAGE. These translate to OBJECT-TYPEs that,
unless otherwise noted below, receive successive arcs in the
output registry tree.
Enumerate all components of base classes before those of their
derivative classes. Thus where a package is refined by a
subclass, first enumerate all components of the base class,
keeping the sequence of the base class PACKAGEs. Explode
ATTRIBUTEs of a derivative class later, enumerating in the
order of specification for that class.
Newnan Expires November 29, 1993 Page 15
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
In the case of multiple inheritance, enumerate contents of
base classes left-to-right and depth first, i.e., enumerate
all components attributable to one immediate base class before
proceeding to the next.
|
+Network -- version
|Management
|V1 (1)
|................................................................
+Trouble -- output subtree
|Administration
|(4)
|................................................................
+t1taTrouble -- class group arc
|ReportTable(5)
|-----------------------------------+----------------+----------
| | |
+--t1taTroubleReportTableEntry(1) +t1taTrouble +t1taTrouble
| | ReportAccess | ReportChild
| | TimeLocation | Table(3)
| | ListTable(2) |
| | |
+--t1taTroubleReportIndex(2) +t1taTrouble +t1taTrouble
| | ReportAccess | ReportChild
| | TimeLocation | TableEntry(3)
| | ListTable |
| | Entry(1) |
+--t1taTroubleReportCancel +--(etc) +--(etc)
| RequestedByManager(2)
|
+--t1taTroubleReportRowStatus(10)
Figure 2. Sample Output Registration Tree
2.2.3 Discussion
RFC 1212 recommends defining a table for every object group
that can be multiply occurring within an agent. It would be
very unusual for a MANAGED OBJECT CLASS not to have
potentially multiple occurrences, especially given a generic
network model that spans systems. To simplify translation,
all object classes map to tables. This tabular approach has
several advantages.
- It supports default values for new object instances.
- It is easy to mechanize, since there is no need to recognize
special cases that are not multiply occurring.
- It simplifies programming of proxy or dual protocol agents,
since the programmer is dealing with basically the same
syntax for scalar items, regardless of protocol.
Newnan Expires November 29, 1993 Page 16
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
The last point applies to both programming effort and
processing overhead. To the extent the elements of syntax are
mapped one-to-one, and underlying syntax is similar or
identical for both protocols, they can be manipulated with
common code and common data structures. This simplifies
translation from both the programming and run-time
perspectives.
The notion of a class InstancePointer is introduced since
direct translation of Distinguished Name's appears
impractical, i.e.,
- A possible ambiguity arises since NAME BINDINGs allow
different object instances of the same MANAGED OBJECT CLASS
to exist under parent objects of different classes.
Likewise, different classes can have the same syntax for
their distinguished attribute(s). Thus, a simple sequence
of attribute values is not sufficient to uniquely
distinguish an object instance.
- NAME BINDINGs allow different instances of the same class to
be subordinate to different types of parent and even allow
instances of a class to be contained recursively within
others of the same class. Thus, in directly translating the
DN one cannot assume a fixed sequence of parameters as
required for by an INDEX clause (DNs for different instances
of the same object class may be have different numbers of
RDNs).
- Both problems could in theory be circumvented by fully
translating the Distinguished Name and incorporating
Attribute Type's as well as Attribute Value's into the
subidentifier OID (in which case the INDEX clause would only
need to specify one index, an OBJECT IDENTIFIER).
While the latter is in theory possible, it would result in
exceedingly verbose subidentifiers, on the order of 70 octets
rather than 7. This is of serious concern due to PDU length
restrictions for SNMP. RFC 1212 proposes a "rule of twenty,"
i.e., no more than twenty attributes per operation. That
guideline was designed for relatively compact subidentifiers.
When using an RDN for an INDEX, this would more likely amount
to a "rule of three," which is why comprehensive translation
of the ISO/CCITT DN to an INDEX appears practical.
The result of this approach is that Distinguished Names are
not translated at all. Similar functionality (naming of
objects) is instead provided by InstancePointers that identify
the table entries corresponding to MANAGED OBJECTs. The
indexes of these tables are arbitrary integers that have no
significance other than to discriminate between entries of a
table. In general, all management information mapped by this
Newnan Expires November 29, 1993 Page 17
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
specification to OBJECT-TYPEs is mapped to tables that have
one or more arbitrary indexes of type INTEGER. Class entries
in particular have exactly one index.
For the following reasons, attributes of [ISO10165-2] Top are
not directly translated into OBJECT-TYPEs.
- Most of these notions would be unfamiliar to the Internet
user and thus their presence would add questionable value.
- Multi-valued attributes would require additional side tables
for all object class groups, which would be cumbersome.
- Managed object class is implicit in the class prefix and
thus does not require a special attribute.
- An allomorphs attribute is supported in ISO/CCITT to allow
dynamic recognition of allomorphs which are supported by an
instance. Since Internet MIB does not support allomorphs at
all -- much less dynamic ones -- there is no reason to list
them.
- Presence or absence of conditional packages can be detected
using a GetNext Request, then determining whether the
conceptual rows returned are the same as expected. No
special attribute is needed for this purpose.
The name binding column of the class table provides a
mechanism by which name bindings can be provided and
inspected. This feature is included for completeness and to
avoid ambiguity. As regards order of enumeration, a left-to-
right sequential approach is the obvious choice for mechanized
translation.
While ISO/CCITT GDMO allows ATTRIBUTEs and ASN.1 syntaxes to
be referenced in multiple places and thus shared, Internet MIB
format does not. Thus one or more OBJECT-TYPEs must be
specified for each template in which they are referenced. The
consequent explosion of enumerated ATTRIBUTEs and ASN.1
syntaxes is a major motivation for a mechanizable procedure
and mechanized translation aids.
2.3 Mapping to the SYNTAX clause
2.3.1 RFC 1212 Advice
When mapping to the SYNTAX clause of the OBJECT-TYPE macro.
(1) An object with BOOLEAN syntax becomes an INTEGER taking
either of values true(1) or false(2).
Newnan Expires November 29, 1993 Page 18
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
(2) An object with ENUMERATED syntax becomes an INTEGER,
taking any of the values given.
(3) An object with BIT STRING syntax containing no more than
32 bits becomes an INTEGER defined as a sum; otherwise if more
than 32 bits are present, the object becomes an OCTET STRING,
with the bits numbered from left-to-right, in which the least
significant bits of the last octet may be "reserved for future
use."
(4) An object with a character string syntax becomes either
an OCTET STRING or a DisplayString, depending on the
repertoire of the character string.
(5) A non-tabular object with a complex syntax, such as REAL
or EXTERNAL, must be decomposed, usually into an OCTET STRING
(if sensible). As a rule, any object with a complicated
syntax should be avoided.
(6) Tabular objects must be decomposed into rows of columnar
objects.
2.3.2 Additional Constraints
2.3.2.1 Simple Input Syntax
Following are rules for translating non-constructed (scalar)
syntax.
For ENUMERATED types, transform to INTEGER, with values of (0)
mapped to (32767).
Where ISO/CCITT management allows certain forms to be present
or not present on a case by case basis (i.e., conditional
packages and ASN.1 OPTIONAL and CHOICE syntaxes)enumerate all
possibilities and allow corresponding conceptual columns to be
conditionally present on a row-by-row basis.
BOOLEANs map to the SNMPv2 TruthValue textual convention.
For CHOICE types, provide an OBJECT-TYPE for every alternative
and populate exactly one of these alternatives per conceptual
row. Document in the DESCRIPTION clause of the generated
columns that exactly one of the choices will be present at any
one time, also, that setting a value for a new type of choice
causes the value for the previously existing option to be
automatically removed from the conceptual row.
For SET OF CHOICE types, a conceptual column is likewise
allocated for every option. However, multiple such options
within a conceptual row may be present at once.
Newnan Expires November 29, 1993 Page 19
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Editor's Note: [Comments are solicited on the correct mapping
for CHOICE and SET OF CHOICE.]
For ASN.1 string types that are subsets of ASCII
(PrintableString, NumericString, IA5String, VisibleString,
etc.) use DisplayString if at all possible. Note that this
imposes a length restriction. Map other string constructs
(e.g., GraphicString) to OCTET STRING. Implementations should
by convention still stick to the NVT ASCII subset where
practical.
In general, treat a constructed type that contains no more
than one scalar (e.g., various forms of string specialization)
as if it were the contained scalar.
2.3.2.2 Complex Input Syntax
Expansion of compound constructors sometimes requires
definition of side tables, ancillary tables within the object
group that supplement the class table corresponding to the
ISO/CCITT GDMO managed object class. The rules for making
side tables are applied recursively and are as follows.
- For a given level of nesting, if the ISO/CCITT GDMO ASN.1
syntax is SEQUENCE (not SEQUENCE OF) or SET (not SET OF)
enumerate its scalar elements "in-line" without constructing
a new side table, and otherwise treat them as if scalars.
- Otherwise (SEQUENCE OF or SET OF) enumerate the scalar
elements of the SEQUENCE or SET in a new side table that is
a dependent of the current table. Since this may happen
recursively, a side table may be a dependent of another side
table.
- The INDEX of a dependent table is that of its superior
concatenated with a value index that uniquely distinguishes
instances within the dependent table.
Editor's Note: [Comment on appropriate treatment of ANY is
requested. Should we use the deprecated form of SNMP? Should
we expand the ANYs for known outcomes? Any other
suggestions?]
2.3.3 Discussion
2.3.3.1 Simple Input Syntax
Internet SMI precludes a named INTEGER value of zero and some
compilers will not accept it. 32767 is a number that
practically any machine architecture can support and is large
enough so it should not conflict with any enumerated actually
Newnan Expires November 29, 1993 Page 20
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
specified. Clearly, collisions can occur, in which case human
judgment is necessary.
Allowing optional conceptual columns within rows is not
consistent with the philosophy of RFC 1212, but neither are
the MIBs the procedure seeks to translate. However, optional
columns can be accommodated by SNMP using the GetNext request.
In that case protocol returns inconsistent object ID prefixes
for any non-present objects, rather than an error condition.
2.3.3.2 Complex Input Syntax
This is the messiest part of the translation process but
cannot be avoided given that the ISO/CCITT GDMO information
model is to be carried over. One way of looking at this is
that constructed types are put in "third normal form," i.e.,
broken up into a set of flat tables each of which has a unique
key. In EVERY case that key is comprised of one or more
ARBITRARY indexes of type INTEGER. The class entries have
exactly one such index. Multi-valued attributes are
represented as side tables that typically have two indexes:
the first BEING the index of the corresponding class entry and
the second an arbitrary integer that distinguishes one
attribute value from another for the multi-valued case. If a
set valued ATTRIBUTE contained a multiply occurring syntax
(e.g., SEQUENCE OF) it would map to a side table with three
indexes of type INTEGER: first, the index of the class entry,
second, the index of the attribute value, and third, the index
of the multiply occurrence of the syntax.
There is no need for explicit pointers from class entries to
side/child tables or vice versa. Given the index of a side
table entry, one can find the corresponding class entry since
the class arc is known and the subidentifier is also known,
i.e., the first index of the side table. Likewise, knowing
the arc for a side table and the index of a corresponding
class entry, one can use the side table arc suffixed by the
index in a GetNextRequest to discover the first entry in the
side table.
A common practice with SNMPv1 is to require the INDEX clause
of a table to reference only attributes contained within that
table. The translation procedure honors that practice by
defining distinct OBJECT-TYPEs for all indices of side tables,
although though a child table only has only one index with a
different value from its parent's.
There may very well be a "natural key" for multi-valued
syntax, e.g., an address or name. In this case, an artificial
index may be inappropriate. Human judgment must weigh whether
there is a "natural" key and whether the length of the
Newnan Expires November 29, 1993 Page 21
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
associated subidentifier would be permissible for purposes of
indexing.
Note: It is not recommended that natural keys be used for
the INDEX parameter of a class table as that will result
in very long subidentifiers and complicate allocation of
indexes for new object creation. Human judgment can be
used to supplement class entry indices with side tables
that provide secondary indices that support access based
on natural keys.
There is no need to actually access OBJECT-TYPES that
correspond to table indices -- you would have to know them
first to read them, and they cannot be changed. Therefore,
their ACCESS clauses specify not-accessible.
2.4 Generation of Internet MIB Identifiers
2.4.1 Translation Procedure
This discussion has two parts:
- definition of notation for mapping rules, and
- rules for name mapping, with examples.
2.4.1.1 Notation
The following variables are used to generate labels.
<ASN.1 id> Identifier of a production rule specified
using Abstract Syntax Notation One (ASN.1),
e.g., "AccessTimeLocationList."
<ATTRIBUTE id> Identifier used for ATTRIBUTE template, e.g.
"Trouble ReportCancelRequestedByManager."
<MANAGED OBJEC Identifier used for MANAGED OBJECT CLASS
CLASS id> template, e.g.,"TroubleReport."
<module prefix An arbitrary literal assigned to the ASN.1
module to be generated, e.g., "t1ta."
Newnan Expires November 29, 1993 Page 22
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
<n> A decimal string literal indicating the
dimension represented by a value index of a
side table. The first dimension corresponds
to the instance of the managed object (i.e.,
class index) and <n> is not concatenated in
its name. <n> is null valued for the second
dimension, which is usually the greatest
dimension, i.e., the standard multi-valued
attribute. Values of <n> for higher
dimensions are decimal literals assigned in
ascending sequence starting with "3," i.e.,
"3," "4," etc. Note: This option is include
for completeness. This is a good example of
case where human judgment should be used
before carrying over full functionality
between MIBs.
Figure 3. Variables for Generating Identifiers
2.4.1.2 Mapping Rules
The following table provides mapping rules for generating
Internet MIB labels. An example is provided for each rule,
based on the sample inputs and outputs of Appendix A.
Newnan Expires November 29, 1993 Page 23
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Identifier Syntax and Example
class table <module prefix> || <MANAGED OBJECT CLASS id>
||"Table"
e.g., t1taTroubleReportTable
class entry <module prefix> || <MANAGED OBJECT CLASSid>
"TableEntry"
e.g., t1taTroubleReportTableEntry
class entry <module prefix> || <MANAGED OBJECT CLASS id>
index || "Index"
e.g., t1taTroubleReportIndex
class entry <module prefix> || <MANAGED OBJECT CLASS id>
column for || <ATTRIBUTE id> || <ASN.1 id>
attribute valu
e.g., t1taTroubleReportTroubleFoundIdentifie
class entry <module prefix> || <MANAGED OBJECT CLASS id>
parent || "Parent"
e.g., t1taTroubleReportParent
class entry na <module prefix> || <MANAGED OBJECT CLASS id>
binding || "NameBinding"
e.g., t1taTroubleReportNameBinding
class entry <module prefix> || <MANAGED OBJECT CLASS id>
RowStatus || "RowStatus"
e.g., t1taTroubleReportRowStatus
Newnan Expires November 29, 1993 Page 24
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Identifier Syntax and Example
side table <module prefix> || <MANAGED OBJECT CLASS id>
|| <ATTRIBUTE id>|| <ASN.1 id>* || "Table"
e.g.,t1taTroubleReportAccessTimeLocationList
Table
side entry <module prefix> ||<MANAGED OBJECT CLASS id>
||<ATTRIBUTE id> || "TableEntry" e.g.,
t1taTroubleReportAccessTimeLocation
ListTable-Entry
side entry cla <moduleprefix> || <MANAGED OBJECT CLASS id>
index <ATTRIBUTE id> || "ClassIndex"
e.g., t1taTroubleReportAccessTimeLocation
ListClass-Index
side entry val <module prefix> || <MANAGED OBJECT CLASS id>
index || <ATTRIBUTE id> || "ValueIndex" || <n>
e.g., t1taTroubleReportAccessTimeLocation
List-ValueIndex
side entry <module prefix> || <MANAGED OBJECT CLASS id>
column for || <ATTRIBUTE id> || <ASN.1 id>
attribute valu e.g., t1taTroubleReportAccessTimeLocation
List-PremisesName
side entry <module prefix> || <MANAGED OBJECT CLASS id>
RowStatus || "RowStatus"
e.g., t1taTroubleReportAccessTimeLocation
List-RowStatus
Newnan Expires November 29, 1993 Page 25
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Identifier Syntax and Example
child table <module prefix> || <MANAGED OBJECT CLASS id>
|| "ChildTable"
e.g.,t1taTroubleReportChildTable
child entry <module prefix> ||<MANAGED OBJECT CLASS id>
"ChildTableEntry"
e.g., t1taTroubleReportChildTableEntry
child entry <moduleprefix> || <MANAGED OBJECT CLASS id>
class index "ChildClassIndex"
e.g., t1taTroubleReportChildClassIndex
child entry <module prefix> || <MANAGED OBJECT CLASS id>
value index || "ChildValueIndex"
e.g., t1taTroubleReportChildValueIndex
child entry <module prefix> || <MANAGED OBJECT CLASS id>
child column || "Child"
e.g., t1taTroubleReportChild
Figure 4a-c. Mapping Rules for Generating Identifiers
* Note: The <ASN.1 id> is only present in the names of
side table objects when its presence is necessary to
unambiguously distinguish the table in question.
The label for the syntax of a (class, child or side) table
entry is the same as that of the table entry itself except the
first character is promoted to upper case, e.g.,
"T1taTroubleReportTableEntry."
2.4.2 Discussion
This approach is verbose but can be mechanized and ambiguities
and collisions should be rare. It has the additional
advantage that names can be used for C and C++ language
program variables without further manipulation.
Separating constituent ids with hyphens would increase
readability and decrease likelihood of ambiguity.
Unfortunately, many Internet MIB compilers do not allow this.
In cases where the same ATTRIBUTE appears in more than one
PACKAGE included in a MANAGED OBJECT CLASS, manual
intervention is necessary to assign distinct labels for the
corresponding OBJECT-TYPEs.
Newnan Expires November 29, 1993 Page 26
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
2.5 Mapping to the ACCESS clause
2.5.1 RFC 1212 Advice
This is straight-forward.
2.5.2 Discussion
Note that ADD-REMOVE and REPLACE map to "write," while GET
maps to "read." There is no direct mapping to SET-TO-DEFAULT,
since SNMP requires values be explicitly set for existing
objects. PERMITTED VALUES are not directly mapped in the
Internet MIB but need to be understood by the management
station.
2.6 Mapping to the STATUS clause
2.6.1 RFC 1212 Advice
This is usually straight-forward; however, some osified-MIBs
use the term "recommended." In this case, a choice must be
made between "mandatory" and "optional."
2.6.2 Additional Constraints
The translation procedure always uses mandatory.
2.6.3 Discussion
Human judgment can qualify this as necessary.
2.7 Mapping to the DESCRIPTION clause
2.7.1 RFC 1212 Advice
This is straight-forward: simply copy the text, making sure
that any embedded double quotation marks are sanitized (i.e.,
replaced with single-quotes or removed).
2.7.2 Additional Constraints
Text in any DEFINED AS specification is ordinarily carried
over verbatim, although some post-processing may be needed to
clarify context. If this information is lacking, the output
DESCRIPTION must at least say so (this may also require post-
processing).
In cases where generated (translated) SNMPv1 objects comply to
SNMPv2 textual conventions, that fact is documented in the
Newnan Expires November 29, 1993 Page 27
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
DESCRIPTION clause (typically, following the general
description of the object).
In cases where there are additional constraints established by
this specification, a statement to that effect referencing
this document is also inserted in the DESCRIPTION clause.
2.8 Mapping to the REFERENCE clause
2.8.1 RFC 1212 Advice
This is straight-forward: simply include a textual reference
to the object being mapped, the document which defines the
object, and perhaps a page number in the document.
2.8.2 Additional Constraints
The translation procedure transcribes the registry of the
ATTRIBUTE to the corresponding OBJECT-TYPE REFERENCE clause,
which ensures that proper ASN.1 syntax for the values of
OBJECT IDENTIFIERs is retained. If any additional information
is to be provided in this value, it must be provided to the
left of the machine readable ASN.1 syntax and separated from
it by a colon, e.g., "ISO 10165-2: joint-iso-ccitt ms (9)
smi(3) part2(2) attribute(7)". This facilitates generation of
proxies.
This usage applies to ALL clauses that are REFERENCE clauses,
e.g., SNMPv1 TRAP-TYPES and SNMPv2 NOTIFICATION-TYPES.
2.9 Mapping to the INDEX clause
2.9.1 RFC 1212 Advice
Decide how instance-identifiers for columnar objects are to be
formed and define this clause accordingly.
2.9.2 Additional Constraints
Use the class entry indexes for the table and any containing
table, as discussed previously. This keeps the index for any
particular kind of table constant and predictable.
2.10 Mapping to the DEFVAL clause
2.10.1 RFC 1212 Advice
Decide if a meaningful default value can be assigned to the
object being mapped, and if so, define the DEFVAL clause
accordingly.
Newnan Expires November 29, 1993 Page 28
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
2.10.2 Additional Constraints
Please see the previous sections on mapping of managed objects
and syntaxes.
2.11 Translation of Actions
2.11.1 RFC 1212 Advice
2.11.1.1 General Advice
Actions are modeled as read-write objects, in which writing a
particular value results in the action taking place.
Usually an INTEGER syntax is used with a distinguished value
provided for each action to which the object provides access.
In addition, there is usually one other distinguished value,
which is the one returned when the object is read.
2.11.1.2 Mapping to the ACCESS clause
Always use read-write.
2.11.1.3 Mapping to the STATUS clause
This is straight-forward.
2.11.1.4 Mapping to the DESCRIPTION clause
This is straight-forward: simply copy the text, making sure
that any embedded double quotation marks are sanitized (i.e.,
replaced with single-quotes or removed).
2.11.1.5 Mapping to the REFERENCE clause
This is straight-forward: simply include a textual reference
to the action being mapped, the document which defines the
action, and perhaps a page number in the document.
2.11.2 Discussion
This is one of the areas where mechanization can at best be an
aid, rather than an automatic solution, to translation. The
RFC 1212 advice provides a point of departure in this regard.
Newnan Expires November 29, 1993 Page 29
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
2.12 Translation of Notifications
2.12.1 Approach
This subsection provides a method whereby notifications are
translated to traps. This method provides the basis for
translation of standard Definition of Management Information
(DMI) [ISO10165-2] NOTIFICATIONs to traps as reflected in
Appendix B. Since use of traps is strongly discouraged in the
Internet community and there is no filtering mechanism in
SNMPv1, such translation should be done sparingly.
The SNMPv2 Party MIB does provide for views which might be
considered a form of event discrimination. Also, the
omibtransSptTrapSuppressionTable defined in Appendix C.1
provides an optional mechanism that can selectively suppress
traps of different types.
In any case:
- mapping of notifications to traps should always have a
documented justification, and
- wherever such mapping is deemed necessary, the standard
traps provided in Appendix B of this specification should be
used, if applicable.
Where translation of NOTIFICATIONs is necessary, the following
method can be used.
(1) Naming and registration are similar to the procedure for
translation of MANAGED OBJECTS. For each input registry
subtree in which there are NOTIFICATIONs or ATTRIBUTEs to be
translated, establish corresponding output registry subtrees
to hold the translated MIBs (in the example of Appendix B, the
output subtrees are osidmiNotifications and osidmiAttributes
respectively).
Generate a separate ASN.1 module for each subtree in which
NOTIFICATIONs to be translated are registered. Mappings of
corresponding ATTRIBUTEs are also incorporated in each such
output module, which may lead to objects (VARIABLES) of the
same registry appearing in different ASN.1 modules.
Assign a module naming prefix for translated ATTRIBUTEs and
NOTIFICATIONs. This must start with a lower case letter
("osidmi" is the prefix for the translated notifications of
Appendix B). Assign the name of the resulting module "MIB" ||
<module prefix> || "SNMPv1". Assign it the registration "{ "
|| <module prefix> || " 0 1 }". Define an OBJECT IDENTIFIER
with the label of <module prefix>, its value equaling the
value of the output subtree.
Newnan Expires November 29, 1993 Page 30
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
(2) For each notification to be mapped list its: identifier;
arc within its input registry subtree; and mandatory
ATTRIBUTEs. For mandatory ATTRIBUTEs, also list the
corresponding syntaxes resolved to.
(3) For each syntax identified in (2), determine a mapping to
the Internet MIB domain. The mapping rules are the same as for
subsection 2.3 (Mapping to the SYNTAX Clause) above, but with
added constraints that resulting syntax must be scalar and of
fixed type (not a CHOICE). Where the rules of subsection 2.3
do not yield such a form, the syntax of DisplayString is used
(as a default). This is an area in which human judgment will
often be required following deterministic translation.
(4) Define an OBJECT-TYPE (variable) for each ATTRIBUTE
identified in (2).
- The label of the resulting object is arrived at by promoting
the first character of the input identifier to upper case
and prepending the prefix of (1). Thus "additionalText"
becomes "osidmiAdditionalText" given the prefix "osidmi."
- The value for the ACCESS clause is always not-accessible.
- The value of the STATUS clause is always mandatory.
- The value of the REFERENCE clause reflects the registration
of the input ATTRIBUTE. The value for this clause also
follows the convention for machine readability described in
subsection 2.8.
- The value of the DESCRIPTION clause is taken from the
BEHAVIOUR DEFINED AS clause, if any. This value is
otherwise empty. This clause will often need to be
supplemented by comments, and should be manually edited if
the full semantics cannot be carried over due to syntactical
or other restrictions.
- The applicable syntax selected in step (3) is used for the
value of the SYNTAX clause.
- The (relative) arc number for the output registry is the
same as for the input registry.
(5) For each input notification, define a corresponding TRAP-
TYPE.
- The label of the resulting trap is the same as for the
notification except that its first letter is promoted to
upper case and the prefix provided in (1) is prepended. For
example, "objectCreation" maps to "osidmiObjectCreation"
given the prefix "osidmi".
Newnan Expires November 29, 1993 Page 31
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
- The VARIABLES parameter reflects all mandatory ATTRIBUTEs as
identified in(2) and translated in (4), plus two variables
that are always present: osidmiManagedObjectInstance and
osidmiAdditionalText.
- The text of the description is the same as for the BEHAVIOUR
DEFINED AS parameter of the corresponding NOTIFICATION, if
any.
- The REFERENCE clause reflects the registry of the input
NOTIFICATION, using the conventions as for machine
readability established in subsection 2.7 above.
- The relative arc number for the output registry (ENTERPRISE
clause) is the same as for the input registry.
Editor's Note: [Comment is requested on how protocol length
restrictions should be dealt with for mapped notifications.]
2.12.2 Discussion
Limitations of this procedure reflect basic functional
differences between the CMIP and SNMP, with much necessarily
lost in translation.
In particular, SNMP Version 1 provides no mechanism for
filtering traps at the source, and the Internet community
frowns on the usage of traps in any case. Thus anyone
translating a MIB according to this procedure should avoid
translating NOTIFICATIONs without good reason. Where this
cannot be avoided, only the minimum necessary functionality
should be carried over -- and the justification for this
should be documented. Such decisions should be made on a
class by class, NOTIFICATION by NOTIFICATION and even
ATTRIBUTE by ATTRIBUTE basis. While translated DMI
NOTIFICATIONs are provided here for the sake of completeness,
it may never be appropriate to use some of these traps.
The method described in the preceding subsection can be
mechanized. However, at best this will provide the human
translator with default options and a point of departure for
making hard choices.
The mapping of all ATTRIBUTE syntaxes to scalar types
simplifies mapping of identifiers and facilitates auto
registry. Notwithstanding, this approach can in certain cases
be ugly and even unworkable. However, that seems to be the
case for any deterministic procedure. Human judgment and
intervention will often be required.
Consider for example the following. One could deal with
optional syntax by defining different variables for reporting
Newnan Expires November 29, 1993 Page 32
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
all optional forms. At the same time one could define "null"
values for each variable. Variables for all options could
then be passed in a trap message, with exactly one of them
non-empty.
However, specification of null values is messy and does not
lend itself to automation. This also complicates assignment of
labels and arcs, since there is a one-to-many mapping.
Furthermore, passing of empty parameters is inefficient and
complicates the work of a manager, which must determine which
variable is "real." In any case, this approach does not
address multi-valued ATTRIBUTEs -- only CHOICEs.
For the translated DMI NOTIFICATIONs of Appendix B, multi-
valued ATTRIBUTEs are dealt with (as necessary) by issuing
separate traps for each attribute value. This is perhaps not
unreasonable for a default approach. For example, it might be
appropriate for reporting certain kinds of ATTRIBUTE change
such as state changes. However, this approach should be used
very, very sparingly if at all.
Editor's Note: [Comment is solicited whether use of the
optional VarBind values in the protocol is a better way to
deal with this problem, or whether some other approach is
appropriate.]
The onAdditionalInformation field provides a place to put
additional information otherwise lost in translation (e.g.,
non-mandatory or multi-valued ATTRIBUTE values). The
implementor should populate this field with self-defining
information that can easily be understood by operations
personnel.
The onManagedObjectInstance variable is used in lieu of the
ManagedObjectClass and ManagedObjectInstance parameters
provided by CMIP.
2.13 Translation of Delete Operations
2.13.1 RFC 1212 Advice
Nonetheless, it is highly useful to provide a means whereby a
conceptual row may be removed from a table. In MIB-II, this
was achieved by defining, for each conceptual row, an integer-
value columnar object. If a management station sets the value
of this object to some value, usually termed "invalid," then
the effect is one of invalidating the corresponding row in the
table. However, it is an implementation-specific matter as to
whether an agent removes an invalidated entry from the table.
Accordingly, management stations must be prepared to receive
tabular information from agents that corresponds to entries
not currently in use. Proper interpretation of such entries
Newnan Expires November 29, 1993 Page 33
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
requires examination of the columnar object indicating the in-
use status.
2.13.2 Additional Constraints
To simplify mechanized translation, RowStatus is provided for
all class tables (and side tables). This is simpler than
trying to determine which classes support manager-initiated
create and delete operations.
Deletion is accomplished by setting RowStatus to "destroy".
Successful deletion of a class instance automatically leads to
deletion of associated side and child table rows. The
operation succeeds or fails as a whole (e.g., if there are
dependents and automatic deletion is not supported, then
nothing is deleted). Instances of side table entries can be
deleted if and only if that is allowed for the associated set
valued ATTRIBUTEs.
2.14 Translation of Create Operations
2.14.1 RFC 1212 Advice
It is also highly useful to have a clear understanding of how
a conceptual row may be added to a table. In Internet, at the
protocol level, a management station issues an SNMP set
operation containing an arbitrary set of variable bindings.
In the case that an agent detects that one or more of those
variable bindings refers to an object instance not currently
available in that agent, it may, according to the rules of the
SNMP, behave according to any of the following paradigms.
(1) It may reject the SNMP set operation as referring to non-
existent object instances by returning a response with the
error-status field set to "noSuchName" and the error-index
field set to refer to the first vacuous reference.
(2) It may accept the SNMP set operation as requesting the
creation of new object instances corresponding to each of the
object instances named in the variable bindings. The value of
each (potentially) newly created object instance is specified
by the "value" component of the relevant variable binding. In
this case, if the request specifies a value for a newly (or
previously) created object that it deems inappropriate by
reason of value orsyntax, then it rejects the SNMP set
operation by responding with the error-status field set to
badValue and the error-index field set to refer to the first
offending variable binding.
(3) It may accept the SNMP set operation and create new
object instances as described in (2) above and, in addition,
Newnan Expires November 29, 1993 Page 34
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
at its discretion, create supplemental object instances to
complete a row in a conceptual table of which the new object
instances specified in the request may be a part.
It should be emphasized that all three of the above behaviors
are fully conforming to the SNMP specification and are fully
acceptable, subject to any restrictions which may be imposed
by access control and/or the definitions of the MIB objects
themselves.
2.14.2 Additional Constraints
2.14.1 Overview
The row creation (and deletion) rules for conceptual rows
created according to this procedure conform to a subset
(refinement) of the SNMPv2 Row Status textual convention.
That subset is required to enforce consistency with the
containment relationships, services and valid object states of
OSI management.
The RowStatus convention defines six possible status values
(states) for a conceptual row: active, notInService, notReady,
createAndGo, createAndWait and destroy. Three of these are
visible to get operations: active and notInService, which map
to existing OSI managed objects, and notReady, which is a
preparatory state during creation of a managed object.
Statuses of createAndGo and createAndWait are transitory
values used by set operations, discussed further below.
The fundamental principle for this subset of RowStatus usage
is that all values of an instance of a class entry remain in a
state consistent with OSI usage so long as Row Status is
active or notInService. This consistency constraint applies
subsequent to every set operation, although the operation may
partially succeed (best efforts). If a set operation is
attempted that in any way violates OSI usage (NAME BINDINGs,
containment, conditional packages, etc.) error-status other
than noError is returned (see below for further discussion of
error-status usage).
While OSI structural notions are translated to Internet MIB
macro format where there is an analog, in many cases there is
no equivalent, e.g., NAME BINDINGs and PACKAGEs. No attempt is
made to define alternative notation in such cases. The source
GDMO specification is the ultimate authority determining valid
state of translated objects, their attributes and
relationships.
For constructs that do not carry over, no attempt is made to
generate corresponding text in DESCRIPTION clauses of the
generated tables and traps/notifications. However,
Newnan Expires November 29, 1993 Page 35
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
DESCRIPTION clause use for RowStatus objects generated in
translation cite this specification explicitly.
2.14.1.1 Status of notInService
Status of notInService is only supported if the corresponding
OSI resource is governed by an Administrative state ATTRIBUTE
that supports a value of "locked". The notInService status is
functionally equivalent to locked, while active status equates
to unlocked (or existing without Administrative state). An
instance of a class entry can have its administrative state
locked or unlocked either by setting the administrative state
column directly or by switching RowStatus between active and
notInService.
The transitory Administrative state of "shutting down" is
reflected in a RowStatus of active until it completes, at
which point RowStatus becomes notInService. In this case, a
response to the set operation is not returned until the
resource is shut down.
2.14.1.2 Status of notReady
A conceptual row with row status of notReady does not (yet)
exist with respect to consistency with OSI usage. It is
impossible for an inconsistentValue error-status to arise when
manipulating a row with this status, since there is no
enforcement of integrity constraints.
However, once a row achieves active or notInService status, it
cannot return to notReady unless first destroyed and
recreated.
2.14.1.3 Row Creation
A basic requirement for creating an instance of a class entry
is that the conceptual row's parent column points to an
existing instance of a superior class entry for which there is
a valid NAME BINDING. In the event there is ambiguity about
which NAME BINDING to use, the OBJECT IDENTIFIER of the NAME
BINDING to be used must be present in the NAME BINDING column
of the class entry being created. If the row is successfully
created, an empty child table is automatically generated for
the new class InstancePointer. The child table of the new
instance's superior is also automatically updated to reflect
the new subordinate.
A class InstancePointer must be created (first set to active
or notInService) in a single operation resulting in a state
consistent with OSI usage. This is accomplished using a
single set operation without setup, or by staging information
Newnan Expires November 29, 1993 Page 36
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
in notReady status and then creating the instance. Creation
is ordinarily accomplished via set of the class
InstancePointer RowStatus to createAndGo, resulting in active
status. For a class having administrative state, this can
alternatively be done by setting RowStatus to createAndWait,
resulting in a new instance in locked state.
In either case, values for conditional packages that need to
be present must be populated when the instance is activated.
Side table instances cannot be created before corresponding
class InstancePointers are created, although they may be
staged in notReady status.
The omibtransSptNextUniqueIndexTable (see Appendix C) provides
a convenient mechanism for agent to supply manager with an
index to create a new conceptual row. The index returned is
unique to the table in question and allows the agent
(optionally) to implement index assignment policies (e.g.,
FIFO or small number) on a per table basis. Implementation of
that table is discretionary. Any valid option for RowStatus
may be used.
2.14.2 Discussion
To support creation of class instances complicates matters
considerably, since the manager and its users must understand
the underlying OSI constructs. This may not always be
appropriate for native SNMP implementations, in which case a
subset can be implemented that does not support create/delete.
To create an object mapping into the ISO/CCITT world requires
that its parent be known, hence the parent table. A child
table is also provided to allow general navigation of the MIB
tree. The name binding table is necessary to determine the
OBJECT IDENTIFIER associated with each parent/child binding.
An SNMP SetRequest needs to contain enough information to
create an internally consistent object from the ISO/CCITT
perspective. The SNMP PDU size restriction could potentially
be a problem, in which case human judgment is needed.
3. Constraints on SNMPv1 Protocol Usage
3.1 Approach
The following assumptions about use of SNMPv1 protocol are
made to facilitate MIB translation.
- The management station will expect that conditional
attributes may not be present on a per conceptual row basis
Newnan Expires November 29, 1993 Page 37
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
and will act appropriately, e.g., use GetNextRequest to test
for presence.
- The management station will expect that access actually
granted may be less than that stated in the ACCESS clause
due to dynamic access controls.
- As discussed above, set operations on RowStaus and
associated objects are constrained to leave the object in a
state consistent with OSI usage. Among other things, that
means that multiple columns having consistency dependencies
must jointly be updated in a single operation when the class
InstancePointer has active or outOfService status.
Mapping of OSI functionality also requires refinements to use
of error-status as documented as follows.
noError No constraints.
tooBig No constraints.
noSuchName Customary usage, but is also returned when an
attempt is made to access an object for which
read access is denied due to access control.
this case, the object is "invisible."
badValue Customary usage, but may be returned due to a
set request that is contrary to the translated
object's BEHAVIOR or PERMITTED VALUES
specifications, or would violate integrity of
the class InstancePointer overall.
readOnly Customary usage, but may be returned due to
access control as well as violated ACCESS
clause.
genErr No constraints.
3.2 Discussion
A "bending" of the rules of SNMPv1 is necessary to map
functionality not really supported in the protocol. Thus an
off-the-shelf manager should be able to interoperate with an
agent that implements a translated MIB but usage of the PDUs
will not be entirely conventional. This is particularly true
for usage of error-status.
Newnan Expires November 29, 1993 Page 38
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
4. SNMPv2 Translation Procedures
4.1 General Approach
Consistent with the section 2 which defines translation in
terms of constraints on existing Internet usage, this section
builds upon the subsections 2.1 and 2.2 of [RFC1452] that
respectively describe conversion from SNMPv1 OBJECT-TYPEs and
TRAP-TYPEs to the SNMPv2 framework.
However, this format is an editorial convenience. The purpose
of this section is to describe the differences between
translated SNMPv1 and SNMPv2 in a succinct and familiar form.
Note however that in practice a translator is unlikely to
translate from GDMO to SNMPv1 then translate that output to
SNMPv2. Translation to either SNMP framework requires deep
knowledge of the original GDMO MIB; translation is best
conceived of as a single input, dual output process.
The philosophy guiding the procedures in this section is as
follows.
(1) Build upon the work of [RFC1452].
(2) Bring SNMPv1 mappings previously defined for IIMCOMIBTRANS
in line with anticipated SNMPv2 usage (e.g., RowStatus). This
includes mapping into common conventions as described in
section 1 above. Relevant textual conventions are cited
directly in their associated SYNTAX clauses rather than as
comments in DESCRIPTION clauses.
(3) Make all other adjustments necessary to compile with
SNMPv2 syntax.
(4) Make optional adjustments sparingly, only when there is a
natural mapping and where mechanized translation is not
difficult to implement.
4.2 Object Definitions
4.2.1 RFC 1452 Advice
In general, conversion of a MIB module does not require the
deprecation of the objects contained therein. Only if the
semantics of an object truly changes should deprecation be
performed.
(1) The IMPORTS statement must reference SNMPv2-SMI, instead
of RFC1155-SMI and RFC-1212.
Newnan Expires November 29, 1993 Page 39
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
(2) The MODULE-IDENTITY macro must be invoked immediately
after any IMPORTs or EXPORTs statement.
(3) For any descriptor which contains the hyphen character,
the hyphen character is removed.
(4) For any object with an integer-valued SYNTAX clause, in
which the corresponding INTEGER does not have a range
restriction (i.e., the INTEGER has neither a defined set
of named-number enumerations nor an assignment of lower-
and upper-bounds on its value), the object must have the
value of its SYNTAX clause changed to Integer32.
(5) For any object with a SYNTAX clause value of an
enumerated INTEGER, the hyphen character is removed from
any named-number labels which contain the hyphen
character.
(6) For any object with a SYNTAX clause value of Counter, the
object must have the value of its SYNTAX clause changed
to Counter32.
(7) For any object with a SYNTAX clause value of Gauge, the
object must have the value of its SYNTAX clause changed
to Gauge32.
(8) For all objects, the ACCESS clause must be replaced by a
MAX-ACCESS clause. The value of the MAX-ACCESS clause is
the same as that of the ACCESS clause unless some other
value makes "protocol sense" as the maximal level of
access for the object. In particular, object types for
which instances can be explicitly created by a protocol
set operation, will have a MAX-ACCESS clause of "read-
create". If the value of the ACCESS clause is "write-
only", then the value of the MAX-ACCESS clause is "read-
write", and the DESCRIPTION clause notes that reading
this object will result implementation-specific results.
(9) For any columnar object which is used solely for instance
identification in a conceptual row, the object must have
the value of its MAX-ACCESS clause set to "not
accessible", unless all columnar objects of the
conceptual row are used for instance identification, in
which case, the MAX-ACCESS clause for one of them must be
something other than "not-accessible".
(10) For all objects, if the value of the STATUS clause is
"mandatory", the value must be replaced with "current".
(11) For all objects, if the value of the STATUS clause is
"optional", the value must be replaced with "obsolete".
(12) For any object not containing a DESCRIPTION clause, the
object must have a DESCRIPTION clause defined.
Newnan Expires November 29, 1993 Page 40
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
(13) For any object corresponding to a conceptual row which
does not have an INDEX CLAUSE, The object must have
either an INDEX clause or an AUGMENTS clause defined.
(14) For any object with an INDEX clause that references an
object with a syntax of NetworkAddress, the value of the
STATUS clause of the both objects is changed to
"obsolete".
(15) For any object containing a DEFVAL clause with an OBJECT
IDENTIFIER value which is expressed as a collection of
sub-identifiers, change the value to reference a single
ASN.1 identifier.
Other changes are desirable, but not necessary.
(1) Creation and deletion of conceptual rows is inconsistent
using the current framework. The SNMPv2 framework
corrects this. As such, if the MIB module undergoes
review early in its lifetime, and it contains conceptual
tables which allow creation and deletion of conceptual
rows, then it may be worthwhile to deprecate the objects
relating to those tables and replacing them with objects
defined using the new approach.
(2) For any object with a string-valued SYNTAX clause, in
which the corresponding OCTET STRING does not have a size
restriction (i.e., the OCTET STRING has no assignment of
lower- and upper-bounds on its length), one might
consider defining the bounds for the size of the object.
(3) For all textual conventions informally defined in the MIB
module, one might consider redefining those conventions
using the TEXTUAL-CONVENTION macro. Such a change would
not necessitate deprecating objects previously defined
using an informal textual convention.
(4) For any object which represents a measurement in some
kind of units, one might consider adding a UNITS clause
to the definition of t
(5) For any conceptual row which is an extension of another
conceptual row, i.e., for which subordinate columnar
objects both exist and are identified via the same
semantics as the other conceptual row, one might consider
using an AUGMENTS clause in place of the INDEX clause for
the object corresponding to the conceptual row which is
an extension.
Finally, when encountering common errors in SNMPv1 MIB
modules:
Newnan Expires November 29, 1993 Page 41
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
(1) For any object with a SYNTAX clause value of an
enumerated INTEGER, if a named-number enumeration is
present with a value of zero, the value of the STATUS
clause of that object is changed to "obsolete".
(2) For any non-columnar object that is instanced as if it
were immediately subordinate to a conceptual row, the
value of the STATUS clause of that object is changed to
"obsolete".
(3) For any conceptual row object that is not contained
immediately subordinate to a conceptual table, the value
of the STATUS clause of that object (and all subordinate
objects) is changed to "obsolete".
4.2.2 Additional Constraints
Translated MIBs must also reference SNMPv2-TC and SNMPv2-CONF.
While translation procedures are designed so objects and
traps/notifications need not be deprecated, two different
ASN.1 output modules are needed to support the same input MIB,
given the incompatible MIB specification macros of the two
SNMP frameworks. Generate the following names for the SNMPv2
module as follows.
- The identifier of the generated ASN.1 module is: "MIB" ||
<module prefix> || "SNMPv2".
- The ASN.1 registry of the generated module is { <output
subtree> 0 2 }.
- The identifier of the MODULE-IDENTITY macro is <module
prefix> || "SNMPv2".
Most values for the MODULE-IDENTITY clauses must be provided
manually. However, a mechanized translator should generate
skeletal text sufficient to compile. The value of the LAST-
UPDATED clause, the macro's identifier and OBJECT-IDENTIFIER
can be automatically generated. The value of that macro
production, which equals the registry of the generated SNMPv2
ASN.1 module, i.e., { <module prefix> 0 2 }.
Map OSI counters and gauges to SNMP equivalents, using the
smallest type that can accommodate the range of values.
Generate an INTEGER type if there are named values (map
enumerates into named values) or if subtyping information is
available, carrying over the values / subtypes. Otherwise,
use Integer32.
Textual conventions are observed as identified in Section 1.
Newnan Expires November 29, 1993 Page 42
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Generated objects showing read-write ACCESS for SNMPv1 reflect
read-create MAX-ACCESS for SNMPv2.
4.2.3 Comments
While at any point there may not be a known NAME BINDING that
would allow a create operation, it is always possible that a
future binding will so allow. Any translated object that can
be written can potentially be created.
Some SNMPv1 compilers take exception if INDEXes are not
conceptual columns within the conceptual rows they index.
This is accommodated in the SNMPv1 mappings and carried over
to SNMPv2.
Information about UNITS can optionally be picked up in a
manual post-processing phase, by examining BEHAVIOR clauses of
mapped ATTRIBUTES and PACKAGEs
4.3 Trap Definitions
If a MIB module is changed to conform to the SNMPv2 framework,
then each occurrence of the TRAP-TYPE macro must be changed to
a corresponding invocation of the NOTIFICATION-TYPE macro.
(1) The IMPORTS statement must not reference RFC-1215.
(2) The ENTERPRISES clause must be removed.
(3) The VARIABLES clause must be renamed to the OBJECTS
clause.
(4) The STATUS clause must be added.
Additional Constraints: STATUS is always current.
(5) The value of an invocation of the NOTIFICATION-TYPE macro
is an OBJECT IDENTIFIER, not an INTEGER, and must be changed
accordingly.
Additional Constraints: This value must be equal to the value
used for the ENTERPRISE clause of the SNMPv1 mapping,
succeeded by the value of the TRAP-TYPE macro of the SNMPv1
mapping, with the combination of the two enclosed in curly
brackets ("{}"). For example, a TRAP-TYPE value of 1 with
ENTERPRISE value onSMI2toInternetNotification in the SNMPv1
framework will map to NOTIFICATION-TYPE value of
{onSMI2toInternetNotification 1 }.
Newnan Expires November 29, 1993 Page 43
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
5. Constraints on SNMPv2 Protocol Usage
5.1 Approach
As with SNMPv1, SNMPv2 set operations on RowStatus and
associated objects are constrained to leave the object in a
state consistent with OSI usage. Among other things, that
means that multiple columns having consistency dependencies
must jointly be updated in a single operation when the class
InstancePointer has status of active or outOfService.
The following table reflects error-status usage for SNMPv2.
noError No constraints, except that certain
conditions are interpreted as errors
that would not otherwise be.
tooBig No constraints.
noSuchName Does not arise.
badValue Does not arise.
readOnly Does not arise.
genErr No constraints.
noAccess No constraints.
wrongType No constraints.
wrongLength No constraints.
wrongEncoding No constraints.
wrongValue No constraints.
noCreation Will be returned if there is no NAME
BINDING permitting row creation.
inconsistentValue Consistency is enforced across a class
InstancePointer, and may apply to the
presence or absence of row entries, as
well as their values.
resourceUnavailable No constraints.
commitFailed No constraints. Note that the class
InstancePointer is still left in
consistent state.
undoFailed No constraints. Note that the class
InstancePointer is still left in
consistent state.
authorizationError No constraints.
notWritable No constraints.
inconsistentName No constraints.
Note that attributes and objects for which read access is
denied due to access control remain invisible, returning
noSuchObject in the VarBind.
5.2 Discussion
The added capabilities of the SNMPv2 protocol allow most
constraints required for translation to SNMPv1 to be relaxed.
Existence of the authorizationError value avoids the contrived
use of readOnly to signal access control violation. The codes
Newnan Expires November 29, 1993 Page 44
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
for authorizationError and inconsistentValue provide
straightforward solutions to the major problems encountered
with SNMPv1 usage.
6. Summary
Given certain assumptions about the use of SNMP (sections 3
and 5), this procedure allows mechanized translation of most
functionality found in ISO/CCITT MIBs to the world of SNMP.
These procedures preserve the basic capability to navigate
ISO/CCITT object relationships, i.e.,
- location of parents (immediately containing objects),
- location of children (immediately contained objects), and
- location of referenced objects.
This approach preserves the capability to create new object
instances and attribute values, even for generic network
models that subsume multiple computer systems and network
elements.
Areas in which significant functionality may be lost during
translation include the following.
- Notifications: A minimalistic set of capabilities are
provided for basic notifications, but more study is needed.
- Actions: These must be dealt with manually, on a case by
case basis.
- Scoping and Filtering: Rudimentary tools are provided for
navigating translated MIBs using SNMP.
7. Acknowledgments
The following individuals have contributed to this effort.
Bob Aronoff - NIST
Jon Biggar - NetLabs
Mary Brady - NIST
April Chang - NetLabs
Ken Chapman - Stratus Computer Inc.
Alice Chen - Boeing
Christopher Crowell - Cabletron Systems
Jock Embry - Opening Technologies
Ian Emsley - Bull S.A
Paul Golick - IBM
Ulrich Gremmelmaier - University of Stuttgart
Pramod Kalyanasundaram - University of Delaware
Ken Hunter - Hewlett-Packard
Lee LaBarre - The MITRE Corporation
Newnan Expires November 29, 1993 Page 45
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
David Liu - Northern Telecom
Jim MacLeod - U S West
Reece Markowsky - OSIWare
Subrata Mazumdar - IBM
Keith McCloghrie - Hughes LAN Systems
Owen Newnan - U S West
Steve Ng - MPR Teltech
Yasuhiro Ohara - NTT
Jong-Tae Park - KyungPook National University
George Pavlou - University College of London
Lisa Phifer - Bellcore
Jim Reilly - Technical Rsch Ctr of Finland
Tom Rutt - AT&T
Adarsh Sethi - University of Delaware
Raj Sirsikar - University of Delaware
Baltej Singh - OSIWare
Mark Smith - Hewlett-Packard
Einar Stefferud - Network Management Associates
Mark Sylor - Digital
Hector Trevino - Bellcore
Huy Truong - Tandem
Al Vincent - U S West
Dean Voiss - NetLabs
David Waitzman - BBN
Graham Wisdom - Timeplex
Yoshi Yamashita - NKK Corporation
Newnan Expires November 29, 1993 Page 46
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
References
[ISO7498-4] ISO/IEC IS 7498-4, Information Processing Systems
- Open Systems Interconnection -Basic Reference Model Part 4 -
Management Framework, 1989.
[ISO8824] ISO/IEC 8824: Information Technology - Open System
Interconnection - Specification of Abstract Syntax Notation
One (ASN.1),1990.
[ISO8825] ISO/IEC 8825: Information Technology - Open System
Interconnection-Specification of Basic Encoding Rules for
Abstract Syntax Notation One (ASN.1),1990.
[ISO9595] ISO/IEC 9595, Information Technology - Open System
Interconnection - Common Management Information Service
Definition, 1991.
[ISO9596-1] ISO/IEC 9596-1, Information Technology - Open
Systems Interconnection - Common Management Information
Protocol - Part 1: Specification, 1991.
[ISO10165-1] ISO/IEC 10165-1: Information Technology - Open
Systems Interconnection - Structure of Management Information
- Part 1: Management Information Model, 1991.
[ISO10165-2] ISO/IEC 10165-2: Information Technology - Open
Systems Interconnection - Structure of Management Information
- Part 2: Definition of Management Information, 1992.
[ISO10165-4] ISO/IEC 10165-4: Information Technology - Open
Systems Interconnection - Structure of Management Information
- Part 4: Guidelines for the Definition of Managed Objects,
1991.
[RFC1155] RFC1155, M. Rose and K. McCloghrie, Structure and
Identification of Management Information for TCP/IP based
internets, May 1990.
[RFC1157] RFC1157, J.D. Case, M.S. Fedor, M.L. Schoffstall,C.
Davin, Simple Network Management Protocol (SNMP), May 1990.
[RFC1212] RFC1212, M. Rose, K. McCloghrie - Editors, Concise
MIB Definitions, March 1991.
[RFC1213] RFC1213, K. McCloghrie and M. Rose - Editors,
Management Information Base for Network Management of TCP/IP-
basedinternets: MIB-II, March 1991.
[RFC1215] RFC1215, M. Rose - Editor, A convention for Defining
Traps for use with the SNMP, March 1991.
Newnan Expires November 29, 1993 Page 47
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
[RFC1441] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser,
Introduction to version 2 of the Internet-standard Network
Management Framework, April 1993.
[RFC1442] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser,
Structure of Management Information for version 2 of the
Simple Network Management Protocol (SNMPv2), April 1993.
[RFC1443] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser,
Textual Conventions for version 2 of the Simple Network
Management Protocol (SNMPv2), April 1993.
[RFC1452] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser,
Coexistence between version 1 and version 2 of the Internet
Network Management Framework, April 1993.
[IIMCIMIBTRANS] ISO/CCITT and Internet Management Coexistence
(IIMC): Translation of Internet MIBs to ISO/CCITT GDMO MIBs,
Draft 2, May 1993.
[IIMCMIB-II] ISO/CCITT and Internet Management Coexistence
(IIMC): Translation of Internet MIB-II (RFC1213) to ISO/CCITT
GDMO MIB, Draft 2, May 1993.
[IIMCPROXY] ISO/CCITT and Internet Management Coexistence
(IIMC): ISO/CCITT to Internet Management Proxy, Draft 2, May
1993.
[IIMCSEC] ISO/CCITT and Internet Management Coexistence
(IIMC): ISO/CCITT to Internet Management Security, Draft 2,
May 1993.
[NMFTR107] NM Forum and X/Open, ISO/CCITT and Internet
Management: Coexistence and Interworking Strategy, Issue 1.0,
October, 1992.
[T1M192] ANSI T1M1.5, Operations, Administration and
Provisioning (OAM&P)-- Services for Interfaces between
Operations Systems across Jurisdictional Boundaries to support
Fault Management -- Trouble Administration, T1LB.262R3-1991,
January 13, 1992.
[USWE92] U S WEST Communications, Inc., U S WEST Network
Interface Specification-- MEDIACC Trouble Administration (TA),
Document Number 77302,* Issue A, May 1992.
* U S WEST Business Resources, Inc., Manager--Information
Release, 1801 California St., Room 1340, Denver CO 80202; 303
298 0117.
Newnan Expires November 29, 1993 Page 48
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Appendix A (Informative): Abridged Example
Following is a fairly brief example that illustrates some, but
not all, aspects of the translation procedure.
The reader can find a more comprehensive example of MIB
translation in [T1M192] and [USWE92], from which
specifications this abridged example is adapted. The reader
will note that this example is highly abridged and differs in
some other respects from those two specifications.
Editor's Note: [Appendix B will be expanded in the next draft
of this document, and will then serve as a more complete
example. This Appendix may then be removed.]
A.1 Input ISO/CCITT Management Information Base
troubleReport MANAGED OBJECT CLASS
DERIVED FROM "T1M1":top; -- ANSI T1M1 variant of top
CHARACTERIZED BY
troubleReportPkg PACKAGE
ATTRIBUTES
cancelRequestedByManager GET-REPLACE
DEFAULT VALUE
TroubleModule.troubleReportCancelRequestedByManagerDefault,
managedObjectInstance GET,
receivedTime GET,
troubleFound GET;
NOTIFICATIONS
"Rec. X.721 | ISO/IEC 10165-2 : 1992":objectCreation,
"Rec. X.721 | ISO/IEC 10165-2 : 1992":objectDeletion,
"T1LB-91-263R1":troubleHistoryEventNotification;;;
CONDITIONAL PACKAGES
troubleReportaccessTimeLocationListPkg PACKAGE
ATTRIBUTES
accessTimeLocationList GET-REPLACE;;
PRESENT IF "an instance supports it.,",
troubleReportperceivedTroubleSeverityPkg PACKAGE
ATTRIBUTES
perceivedTroubleSeverity GET-REPLACE;;
PRESENT IF "an instance supports it.";
REGISTERED AS { trMObjectClass 5};
accessTimeLocationList ATTRIBUTE
WITH ATTRIBUTE SYNTAX
TroubleModule.ServiceLocationList;
BEHAVIOUR
Newnan Expires November 29, 1993 Page 49
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
accessTimeLocationListBehaviour BEHAVIOUR
DEFINED AS
"The Access Time Location list attribute identifies the set or
subset of service locations for which the Location Access
Hours attribute values are valid.";
;
REGISTERED AS { trAttribute 2};
cancelRequestedByManager ATTRIBUTE
WITH ATTRIBUTE SYNTAX
TroubleModule.CancelRequestedByManager;
MATCHES FOR EQUALITY;
BEHAVIOUR
cancelRequestedByManagerBehaviour BEHAVIOUR
DEFINED AS
"The Cancel Requested By Manager attribute indicates whether
the manager has initiated the process to cancel a Trouble
Report.";
;
REGISTERED AS {trAttribute 12};
managedObjectInstance ATTRIBUTE
WITH ATTRIBUTE SYNTAX
TroubleModule.ManagedObjectInstance;
MATCHES FOR EQUALITY;
BEHAVIOUR
managedObjectInstanceBehaviour BEHAVIOUR
DEFINED AS
"The Managed Object Instance attribute indicates the CNM
Service object class instance or the GNM telecommunications
network resource instance associated with a particular trouble
report instance.";
;
REGISTERED AS {trAttribute 29};
perceivedTroubleSeverity ATTRIBUTE
WITH ATTRIBUTE SYNTAX
TroubleModule.PerceivedTroubleSeverity;
MATCHES FOR EQUALITY;
BEHAVIOUR
perceivedTroubleSeverityBehaviour BEHAVIOUR
DEFINED AS
"The Perceived Trouble Severity attribute allows the manager
to indicate the effect of the trouble on the managed object
being reported.";
;
REGISTERED AS {trAttribute 32};
receivedTime ATTRIBUTE
WITH ATTRIBUTE SYNTAX TroubleModule.ReceivedTime;
MATCHES FOR ORDERING;
BEHAVIOUR
receivedTimeBehaviour BEHAVIOUR
DEFINED AS
Newnan Expires November 29, 1993 Page 50
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
"The Received Time attribute indicates the date and
time when a trouble report was entered.";
;
REGISTERED AS {trAttribute 33};
troubleFound ATTRIBUTE
WITH ATTRIBUTE SYNTAX TroubleModule.TroubleFound;
BEHAVIOUR
troubleFoundBehaviour BEHAVIOUR
DEFINED AS
"The Trouble Found attribute specifies an enumerated code
value, which identifies the problem resolved. This field will
be copied into the trouble history information.";
;
REGISTERED AS {trAttribute 45};
troubleHistoryEventNotification NOTIFICATION
WITH INFORMATION SYNTAX
TroubleModule.TroubleHistoryInfo;
REGISTERED AS {trNotification 1};
TroubleModule DEFINITIONS ::=
-- TroubleModule {...troubleModule(x)}
BEGIN
IMPORTS
AdditionalTroubleInfo,
CancelRequestedByManger,
CloseoutVerification,
CommitmentTime,
PerceivedTroubleSeverity,
TroubleFound,
TroubleReportNumberList,
TroubleType FROM GNMTA
ObjectInstance FROM CMIP-1 {joint-iso-ccitt ms(9)
cmip(1) modules(0) protocol(3)};
trMObjectClass OBJECT IDENTIFIER ::= { iso(1) member-body(2)
usa(840) ansi-t1-227-1992(10015) trGNM(0) objectClass(3) }
trAttribute OBJECT IDENTIFIER ::= { iso(1) member-body(2)
usa(840) ansi-t1-227-1992(10015) trGNM(0) attribute(7) }
trNotification OBJECT IDENTIFIER ::= { iso(1) member-body(2)
usa(840) ansi-t1-228-1992(10016) trGNM(0) notification(10) }
CancelRequestedByManager ::= BOOLEAN
ManagedObjectInstance ::= ObjectInstance
Newnan Expires November 29, 1993 Page 51
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
PerceivedTroubleSeverity ::= INTEGER {
outOfService(0),
backInService(1),
serviceAffectingTrouble(2),
nonServiceAffectingTrouble(3)
}
PremisesAddress ::= PrintableString(SIZE(128))
PremisesName ::= PrintableString(SIZE(64))
ReceivedTime ::= GeneralizedTime
ServiceLocationList ::= SET OF SEQUENCE{
PremisesName,
PremisesAddress
}
TroubleFound ::= CHOICE{
number INTEGER {
pending(0),
cameClear(1),
centralOffice(2),
customerPremisesEquipment(3),
facility(4),
interexchangeCarrier(5),
information(6),
nonplanClassified(7),
noTroubleFound(8),
station(9),
servingBureau(10),
testOK(11),
publicServicesCoinSet(12),
otherStationEquipment(13),
stationWiring(14),
centralOfficeFacility(15),
customerOperatingInstructions(16),
testedOKVerifiedOK(17),
coFacilityTestedFoundOK(18),
outsideFacilityTestedFoundOK(19),
referredOutToOtherDept(20),
protectiveConnectingArrang(21),
cpeCustomerResponsibility(22)
},
identifier OBJECT IDENTIFIER
}
troubleReportCancelRequestedByManagerDefault BOOLEAN ::=
FALSE
-- Supporting Productions
TroubleAdministrationFunctionalUnits ::= BIT STRING
{
fm-ta-kernel (0),
fm-ta-req-trb-rpt-format (1),
fm-ta-trb-hist-evt- notif (2),
fm-ta-rev-trb-hist-recd (3),
fm-ta-add-trb-info (4),
fm-ta-trb-rpt-up-notif (5),
Newnan Expires November 29, 1993 Page 52
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
fm-ta-enrol-deenrol-notif (6),
fm-ta-ver-trb-rep-comp (7),
fm-ta-mod-trb-adm-info (8)
}
TroubleHistoryInfo ::= SEQUENCE{
managedObjectInstance [0] ObjectInstance,
receivedTime [1] GeneralizedTime,
troubleFound [2] TroubleFound,
additionalTroubleInfo [3] AdditionalTroubleInfo
OPTIONAL,
cancelRequestedByManager [4] CancelRequestedByManager
OPTIONAL,
closeOutNarr [5] PrintableString OPTIONAL,
closeoutVerification [6] CloseoutVerification
OPTIONAL,
commitmentTime [7] CommitmentTime OPTIONAL,
custTroubleTicketNumber [8] PrintableString
OPTIONAL,
perceivedTroubleSeverity [9] PerceivedTroubleSeverity
OPTIONAL,
restoredTime [10] GeneralizedTime OPTIONAL,
troubleReportNumberList [11] TroubleReportNumberList
OPTIONAL,
troubleType [12] TroubleType OPTIONAL
}
END
A.2 Output SNMPv1 Management Information Base
MIBt1taSNMPv1 DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-TYPE, internet
FROM RFC1155-SMI;
-- IMPORTS may of course include a minimalistic subset as an
-- optimization (as illustrated above), however,
-- boilerplate for generated code may contain IMPORTS not
-- used.
-- The example which follows is similar to what might be
-- generated using a mechanized translator except that
-- it is liberally interspersed with comments.
-- Generated code must clearly indicated ASN.1 registry of
-- the module, in the DEFINITIONS production and/or in
-- comments. Note, some SNMPv1 parsers cannot handle
-- registry of modules, so a translator should provide an
-- option whereby this information is included as comments.
-- Such information is not provided here, since this is
-- a fabricated example. OIDs for trAttribute and
Newnan Expires November 29, 1993 Page 53
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
-- trMobjectClass would also be provided for a real MIB.
-- If this were a normative example, a production of the form
-- t1ta OBJECT IDENTIFIER ::= { ... } would be present.
-- The registry of this ASN.1 module would then be
-- { t1ta 0 1 }, the SNMPv1 version of
-- Trouble Administration.
t1ta OBJECT IDENTIFIER ::= { ? }
-- *******************************************************
-- This example illustrates a single translated object
-- group class table, a side table (corresponding to a
-- multi-valued attribute) and a child table.
-- This example illustrates among other things
-- translation of enumerateds, timestamps, BOOLEANs,
-- CHOICEs, ObjectInstance's and default values to SNMPv1.
-- *******************************************************
-- The general structure of this module (indentation
-- reflects the OID structure) is:
-- t1taTroubleReportTable
-- t1taTroubleReportTableEntry
-- t1taTroubleReportIndex
-- t1taTroubleReportCancelRequestedByManager
-- t1taTroubleReportManagedObjectInstance
-- t1taTroubleReportReceivedTime
-- t1taTroubleReportTroubleFoundNumber
-- t1taTroubleReportTroubleFoundIdentifier
-- t1taTroubleReportPerceivedTroubleSeverity
-- t1taTroubleReportRowParent
-- t1taTroubleReportRowNameBinding
-- t1taTroubleReportRowStatus
-- t1taTroubleReportAccessTimeLocationListTable
-- t1taTroubleReportAccessTimeLocationListTableEntry
-- t1taTroubleReportAccessTimeLocationListClassIndex
-- t1taTroubleReportAccessTimeLocationListValueIndex
-- t1taTroubleReportAccessTimeLocationListPremisesName
-- t1taTroubleReportAccessTimeLocationList-
-- PremisesAddress
-- t1taTroubleReportAccessTimeLocationListRowStatus
-- t1taTroubleReportChildTable
-- t1taTroubleReportChildTableEntry
-- t1taTroubleReportChildClassIndex
-- t1taTroubleReportChildValueIndex
-- t1taTroubleReportChild
-- **********************************************************
Newnan Expires November 29, 1993 Page 54
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
t1taTroubleReportTable OBJECT-TYPE
-- class table
SYNTAX SEQUENCE OF T1TATroubleReportTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"t1taTroubleReport class table."
REFERENCE "trMobjectClass 5"
::= { t1ta 5 }
-- 5th object in TA Input and Output Subtrees
t1taTroubleReportTableEntry OBJECT-TYPE
-- class table entry
SYNTAX T1TATroubleReportTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"t1taTroubleReportTable instance"
INDEX { t1taTroubleReportIndex }
::= { t1taTroubleReportTable 1 }
T1TATroubleReportTableEntry ::= SEQUENCE {
t1taTroubleReportIndex
INTEGER,
t1taTroubleReportCancelRequestedByManager
INTEGER,
t1taTroubleReportManagedObjectInstance
OBJECT IDENTIFIER,
t1taTroubleReportReceivedTime
DisplayString, -- DateAndTime
t1taTroubleReportTroubleFoundNumber
INTEGER,
t1taTroubleReportTroubleFoundIdentifier
OBJECT IDENTIFIER,
t1taTroubleReportPerceivedTroubleSeverity
INTEGER,
t1taTroubleReportParent
OBJECT IDENTIFIER,
t1taTroubleReportNameBinding
OBJECT IDENTIFIER,
t1taTroubleReportRowStatus
INTEGER
}
t1taTroubleReportIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS not-accessible
STATUS mandatory
Newnan Expires November 29, 1993 Page 55
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
DESCRIPTION
"Provides the index by which instances of
t1taTroubleReport table entries are distinguished."
::= { t1taTroubleReportTableEntry 1 }
t1taTroubleReportCancelRequestedByManager OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Cancel Requested By Manager attribute indicates
whether the manager has initiated the process to cancel
a Trouble Report.
This object complies with the TruthValue textual
convention of the SNMPv2 framework per RFC 1443. It is
functionally equivalent to a BOOLEAN type but takes
different values."
-- Note that text citing the SNMPv2 convention is
-- concatenated to text from the input BEHAVIOUR
-- specification.
REFERENCE "trAttribute 12"
DEFVAL { 1 } -- TruthValue usage for FALSE
-- troubleReportCancelRequestedByManagerDefault
-- BOOLEAN ::= FALSE
::= { t1taTroubleReportTableEntry 2 }
t1taTroubleReportManagedObjectInstance OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Managed Object Instance attribute indicates the CNM
Service object class instance or the GNM
telecommunications network resource instance associated
with a particular trouble report instance.
This object complies with the RFC 1443 InstancePointer
textual convention of the SNMPv2 framework, which
defines an OBJECT IDENTIFIER pointer to a conceptual
row."
REFERENCE "trAttribute 29"
::= { t1taTroubleReportTableEntry 3 }
t1taTroubleReportReceivedTime OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
Newnan Expires November 29, 1993 Page 56
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
STATUS mandatory
DESCRIPTION
"The Received Time attribute indicates the date and
time when a trouble report was entered.
This object complies with the DateAndTime textual
convention of the SNMPv2 framework per RFC 1443.
DateAndTime reports local time in a standard format."
REFERENCE "trAttribute 33"
::= { t1taTroubleReportTableEntry 4 }
-- Note that t1taTroubleReportAccessTimeLocationList is not
-- assigned arc 5 because it is implemented as a side table
-- due to its set valued syntax; see below.
-- The following illustrates mapping of a CHOICE.
-- Exactly one of the following two choices will be present
-- for a given class instance.
-- These are enumerated in-line (in the
-- class table) rather than in a side table because the
-- syntax cannot be multi-valued.
t1taTroubleReportTroubleFoundNumber OBJECT-TYPE
SYNTAX INTEGER {
-- Note that INTEGERs of enumerated value can be mapped
-- as comments or formal syntax.
pending(32767),-- value of zero not permitted
cameClear(1),
centralOffice(2),
customerPremisesEquipment(3),
facility(4),
interexchangeCarrier(5),
information(6),
nonplanClassified(7),
noTroubleFound(8),
station(9),
servingBureau(10),
testOK(11),
publicServicesCoinSet(12),
otherStationEquipment(13),
stationWiring(14),
centralOfficeFacility(15),
customerOperatingInstructions(16),
testedOKVerifiedOK(17),
coFacilityTestedFoundOK(18),
outsideFacilityTestedFoundOK(19),
referredOutToOtherDept(20),
protectiveConnectingArrang(21),
cpeCustomerResponsibility(22)
}
ACCESS read-only
Newnan Expires November 29, 1993 Page 57
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
STATUS mandatory
DESCRIPTION
"The Trouble Found attribute specifies an enumerated
code value, which identifies the problem resolved. This
field will be copied into the trouble history
information."
REFERENCE "trAttribute 45"
::= { t1taTroubleReportTableEntry 5}
t1taTroubleReportTroubleFoundIdentifier OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Trouble Found attribute specifies an enumerated
code value, which identifies the problem resolved. This
field will be copied into the trouble history
information."
REFERENCE "trAttribute 45"
::= { t1taTroubleReportTableEntry 6}
t1taTroubleReportPerceivedTroubleSeverity OBJECT-TYPE
SYNTAX INTEGER {
outOfService(32767), -- mapped from zero
backInService(1),
serviceAffectingTrouble(2),
nonServiceAffectingTrouble(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Perceived Trouble Severity attribute allows the
manager to indicate the effect of the trouble on the
managed object being reported"
REFERENCE "trAttribute 32"
::= { t1taTroubleReportTableEntry 7}
t1taTroubleReportParent OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object is used to specify the superior class
entry instance when creating a subordinate class entry
instance. Likewise, it can be queried to determine the
superior class instance (if any) for an
existing class instance.
Newnan Expires November 29, 1993 Page 58
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
This object complies with the RFC 1443 InstancePointer
textual convention of the SNMPv2 framework, which
defines an OBJECT IDENTIFIER pointer to a conceptual
row.
Behavior of this object furthermore conforms to the
specifications of IIMCOMIBTRANS
({ iimcManagement 3 1 5 })
subsections 2.13 and 2.14 that
enforce consistency with OSI management
containment relationships, abstract services and
permissible object states."
::= { t1taTroubleReportTableEntry 8 }
t1taTroubleReportNameBinding OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object allows specification of a
specific NAME BINDING for creation of a class entry
instance. It can also be examined to
determine the NAME BINDING in effect for an existing
class table instance.
Use of this object must conform to the specifications
of IIMCOMIBTRANS ({ iimcManagement 3 1 5 })
subsections 2.13 and 2.14 which
enforce consistency with OSI management
containment relationships, abstract services and
permissible object states."
::= { t1taTroubleReportTableEntry 9 }
t1taTroubleReportRowStatus OBJECT-TYPE
SYNTAX INTEGER -- conforms to SNMPv2 RowStatus usage
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object complies with the RowStatus textual
convention of the SNMPv2 framework per RFC 1443.
The RowStatus convention specifies elements of procedure
for creation, deletion and state management of
conceptual rows.
Behavior of this object furthermore conforms to
subsections 2.13 and 2.14 of IIMCOMIBTRANS
({ iimcManagement 3 1 5 }), that
enforce consistency with OSI management
containment relationships, abstract services and
Newnan Expires November 29, 1993 Page 59
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
permissible object states.
These subsections specify constraints (refinements) to
RowStatus usage beyond what is specified by RFC 1443."
::= { t1taTroubleReportTableEntry 10 }
-- ********************************************************
-- The following is a side table because it is translated
-- from a multi-valued attribute:
t1taTroubleReportAccessTimeLocationListTable OBJECT-TYPE
SYNTAX SEQUENCE OF
T1TATroubleReportAccessTimeLocationListTableEntry
ACCESS not-accessible
STATUS mandatory
-- This attribute is in a conditional package, so it
-- may be absent from a given conceptual row.
DESCRIPTION
"The Access Time Location list attribute identifies the
set or subset of service locations for which the
Location Access Hours attribute values are valid."
REFERENCE "trAttribute 2"
::= { t1taTroubleReportTable 2 }
t1taTroubleReportAccessTimeLocationListTableEntry OBJECT-TYPE
SYNTAX T1TATroubleReportAccessTimeLocationListTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"t1taTroubleReportAccessTimeLocationListTable entry."
INDEX {
t1taTroubleReportAccessTimeLocationListClassIndex,
t1taTroubleReportAccessTimeLocationListValueIndex
}
::= { t1taTroubleReportAccessTimeLocationListTable 1 }
T1TATroubleReportAccessTimeLocationListTableEntry
::= SEQUENCE {
t1taTroubleReportAccessTimeLocationListClassIndex
INTEGER,
t1taTroubleReportAccessTimeLocationListValueIndex
INTEGER,
t1taTroubleReportAccessTimeLocationListPremisesName
DisplayString,
t1taTroubleReportAccessTimeLocationListPremisesAddress
DisplayString,
t1taTroubleReportAccessTimeLocationListRowStatus
INTEGER
Newnan Expires November 29, 1993 Page 60
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
}
t1taTroubleReportAccessTimeLocationListClassIndex OBJECT-TYPE
-- side table class index
SYNTAX INTEGER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Has same value as class entry index of managed object."
::= { t1taTroubleReportAccessTimeLocationListTableEntry 1 }
t1taTroubleReportAccessTimeLocationListValueIndex OBJECT-TYPE
-- side table value index
SYNTAX INTEGER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Uniquely discriminates a value of
t1taTroubleReportAccessTimeLocationList within a managed
object"
::= { t1taTroubleReportAccessTimeLocationListTableEntry 2 }
t1taTroubleReportAccessTimeLocationListPremisesName
OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The access time for a service location list premises
name."
::= { t1taTroubleReportAccessTimeLocationListTableEntry 30 }
t1taTroubleReportAccessTimeLocationListPremisesAddress
OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The access time for a service location list premises
address."
::= { t1taTroubleReportAccessTimeLocationListTableEntry 4 }
t1taTroubleReportAccessTimeLocationListRowStatus OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object complies with the RowStatus textual
convention of the SNMPv2 framework per RFC 1443.
Newnan Expires November 29, 1993 Page 61
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
The RowStatus convention specifies elements of procedure
for creation, deletion and state management of
conceptual rows.
Behavior of this object furthermore conforms to
subsections 2.13 and 2.14 of IIMCOMIBTRANS
({ iimcManagement 3 1 5 }), that
enforce consistency with OSI management
containment relationships, abstract services and
permissible object states.
These subsections specify constraints (refinements) to
RowStatus usage beyond what is specified by RFC 1443."
::= { t1taTroubleReportAccessTimeLocationListTableEntry 5 }
-- ******************************************************
t1taTroubleReportChildTable OBJECT-TYPE
SYNTAX SEQUENCE OF T1TATroubleReportChildTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Allows children in the ISO/CCITT Management naming
hierarchy to be returned."
::= { t1taTroubleReportTable 3 }
t1taTroubleReportChildTableEntry OBJECT-TYPE
SYNTAX T1TATroubleReportChildTableEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entry of Child table."
INDEX {
t1taTroubleReportChildClassIndex,
t1taTroubleReportChildValueIndex
}
::= { t1taTroubleReportChildTable 1 }
T1TATroubleReportChildTableEntry ::= SEQUENCE {
t1taTroubleReportChildClassIndex INTEGER,
t1taTroubleReportChildValueIndex INTEGER,
t1taTroubleReportChild OBJECT IDENTIFIER
-- RowStatus is not applicable
}
t1taTroubleReportChildClassIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS not-accessible
Newnan Expires November 29, 1993 Page 62
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
STATUS mandatory
DESCRIPTION
"Implicit index value of class table."
::= {t1taTroubleReportChildTableEntry 1}
t1taTroubleReportChildValueIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Implicit index value of child table."
::= {t1taTroubleReportChildTableEntry 2}
t1taTroubleReportChild OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This parameter is typically used in conjunction with a
get next operation to determine class instances
for successive child (contained) objects within the
parent (superior object).
This object complies with the RFC 1443 InstancePointer
textual convention of the SNMPv2 framework, which
defines an OBJECT IDENTIFIER pointer to a conceptual
row.
Behavior of this object furthermore conforms to the
specifications of IIMCOMIBTRANS
({ iimcManagement 3 1 5 })
subsections 2.13 and 2.14 that
enforce consistency with OSI management
containment relationships, abstract services and
permissible object states."
::= {t1taTroubleReportChildTableEntry 3 }
END
A.3 Output SNMPv2 Management Information Base
MIBt1taSNMPv2 DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Integer32, internet, snmpModules
Newnan Expires November 29, 1993 Page 63
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
FROM SNMPv2-SMI
DateAndTime, DisplayString, InstancePointer, RowStatus,
TruthValue
FROM SNMPv2-TC
OBJECT-GROUP FROM SNMPv2-CONF;
t1taSNMPv2 MODULE-IDENTITY
-- ID of MODULE-IDENTITY is same as for containing module
-- except stripped of the prefix "MIB".
LAST-UPDATED "9305250000Z"
ORGANIZATION "Network Management Forum"
CONTACT-INFO
"Owen Newnan * U S WEST Advanced Technologies
4001 Discovery Avenue Suite 190
Boulder, CO 80303
303 541-6253 fax x6250 * onewnan@advtech.uswest.com"
DESCRIPTION
"Provides sample SNMPv2 output for the (informative)
example of IIMCOMIBTRANS."
::= { t1ta 0 2 } -- SNMPv2 registry of this translation.
-- The example which follows is similar to what might be
-- generated using a mechanized translator except that
-- it is liberally interspersed with comments.
-- If this were a normative example, a production of the form
-- t1ta OBJECT IDENTIFIER ::= { ... } would be present.
t1ta OBJECT IDENTIFIER ::= { TBD }
-- IMPORTS may of course include a minimalistic subset as an
-- optimization (as illustrated above), however,
-- boilerplate for generated code may contain IMPORTS not
-- used.
-- Generated code must clearly indicated ASN.1 registry of
-- the module, in the DEFINITIONS production and/or in
-- comments. OIDs for trAttribute and
-- trMobjectClass would also be provided for a real MIB.
-- *******************************************************
-- This example illustrates a single translated object
-- group class table, a side table (corresponding to a
-- multi-valued attribute) and a child table.
-- This example illustrates among other things
-- translation of enumerateds, timestamps, BOOLEANs,
-- CHOICEs, ObjectInstance's and default values to SNMPv2.
Newnan Expires November 29, 1993 Page 64
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
-- It also illustrates similarities and differences between
-- translated SNMPv1 and SNMPv2 outputs.
-- *******************************************************
-- The general structure of this module (indentation
-- reflects the OID structure) is:
-- t1taTroubleReportTable
-- t1taTroubleReportTableEntry
-- t1taTroubleReportIndex
-- t1taTroubleReportCancelRequestedByManager
-- t1taTroubleReportManagedObjectInstance
-- t1taTroubleReportReceivedTime
-- t1taTroubleReportTroubleFoundNumber
-- t1taTroubleReportTroubleFoundIdentifier
-- t1taTroubleReportPerceivedTroubleSeverity
-- t1taTroubleReportRowParent
-- t1taTroubleReportRowNameBinding
-- t1taTroubleReportRowStatus
-- t1taTroubleReportAccessTimeLocationListTable
-- t1taTroubleReportAccessTimeLocationListTableEntry
-- t1taTroubleReportAccessTimeLocationListClassIndex
-- t1taTroubleReportAccessTimeLocationListValueIndex
-- t1taTroubleReportAccessTimeLocationListPremisesName
-- t1taTroubleReportAccessTimeLocationList-
-- PremisesAddress
-- t1taTroubleReportAccessTimeLocationListRowStatus
-- t1taTroubleReportChildTable
-- t1taTroubleReportChildTableEntry
-- t1taTroubleReportChildClassIndex
-- t1taTroubleReportChildValueIndex
-- t1taTroubleReportChild
-- *******************************************************
t1taTroubleReportTable OBJECT-TYPE
-- class table
SYNTAX SEQUENCE OF T1TATroubleReportTableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"t1taTroubleReport class table."
REFERENCE "trMobjectClass 5"
::= { t1ta 5 }
-- 5th object in TA Input and Output Subtrees
t1taTroubleReportTableEntry OBJECT-TYPE
-- class table entry
SYNTAX T1TATroubleReportTableEntry
Newnan Expires November 29, 1993 Page 65
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"t1taTroubleReportTable instance"
INDEX { t1taTroubleReportIndex }
::= { t1taTroubleReportTable 1 }
T1TATroubleReportTableEntry ::= SEQUENCE {
t1taTroubleReportIndex
Integer32,
t1taTroubleReportCancelRequestedByManager
TruthValue,
t1taTroubleReportManagedObjectInstance
InstancePointer,
t1taTroubleReportReceivedTime
DateAndTime,
t1taTroubleReportTroubleFoundNumber
Integer32,
t1taTroubleReportTroubleFoundIdentifier
OBJECT IDENTIFIER,
t1taTroubleReportPerceivedTroubleSeverity
Integer32,
t1taTroubleReportParent
InstancePointer,
t1taTroubleReportNameBinding
OBJECT IDENTIFIER,
t1taTroubleReportRowStatus
RowStatus
}
t1taTroubleReportIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Provides the index by which instances of
t1taTroubleReport table entries are distinguished."
::= { t1taTroubleReportTableEntry 1 }
t1taTroubleReportCancelRequestedByManager OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Cancel Requested By Manager attribute indicates
whether the manager has initiated the process to cancel
a Trouble Report."
REFERENCE "trAttribute 12"
Newnan Expires November 29, 1993 Page 66
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
DEFVAL { 1 } -- TruthValue usage for FALSE
-- troubleReportCancelRequestedByManagerDefault
-- BOOLEAN ::= FALSE
::= { t1taTroubleReportTableEntry 2 }
t1taTroubleReportManagedObjectInstance OBJECT-TYPE
SYNTAX InstancePointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Managed Object Instance attribute indicates the
CNM Service object class instance or the GNM
telecommunications network resource instance associated
with a particular trouble report instance."
REFERENCE "trAttribute 29"
::= { t1taTroubleReportTableEntry 3 }
t1taTroubleReportReceivedTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Received Time attribute indicates the date and time
when a trouble report was entered."
REFERENCE "trAttribute 33"
::= { t1taTroubleReportTableEntry 4 }
-- Note that t1taTroubleReportAccessTimeLocationList is not
-- assigned arc 5 because it is implemented as a side table
-- due to its set valued syntax; see below.
-- The following illustrates mapping of a CHOICE.
-- Exactly one of the following two choices will be present
-- for a given class entry.
-- These are enumerated in-line (within the
-- class table) rather than in a side table because the
-- syntax cannot be multi-valued.
t1taTroubleReportTroubleFoundNumber OBJECT-TYPE
SYNTAX INTEGER {
-- Note that INTEGERs of enumerated value can be mapped
-- as comments or formal syntax.
pending(32767),-- value of zero not permitted
cameClear(1),
centralOffice(2),
customerPremisesEquipment(3),
facility(4),
interexchangeCarrier(5),
Newnan Expires November 29, 1993 Page 67
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
information(6),
nonplanClassified(7),
noTroubleFound(8),
station(9),
servingBureau(10),
testOK(11),
publicServicesCoinSet(12),
otherStationEquipment(13),
stationWiring(14),
centralOfficeFacility(15),
customerOperatingInstructions(16),
testedOKVerifiedOK(17),
coFacilityTestedFoundOK(18),
outsideFacilityTestedFoundOK(19),
referredOutToOtherDept(20),
protectiveConnectingArrang(21),
cpeCustomerResponsibility(22)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Trouble Found attribute specifies an enumerated
code value, which identifies the problem resolved. This
field will be copied into the trouble history
information."
REFERENCE "trAttribute 45"
::= { t1taTroubleReportTableEntry 5}
t1taTroubleReportTroubleFoundIdentifier OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Trouble Found attribute specifies an enumerated
code value, which identifies the problem resolved. This
field will be copied into the trouble history
information."
REFERENCE "trAttribute 45"
::= { t1taTroubleReportTableEntry 6}
t1taTroubleReportPerceivedTroubleSeverity OBJECT-TYPE
SYNTAX INTEGER {
outOfService(32767), -- mapped from zero
backInService(1),
serviceAffectingTrouble(2),
nonServiceAffectingTrouble(3)
}
MAX-ACCESS read-create
STATUS current
Newnan Expires November 29, 1993 Page 68
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
DESCRIPTION
"The Perceived Trouble Severity attribute allows the
manager to indicate the effect of the trouble on the
managed object being reported"
REFERENCE "trAttribute 32"
::= { t1taTroubleReportTableEntry 7}
t1taTroubleReportParent OBJECT-TYPE
SYNTAX InstancePointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object is used to specify the superior class
entry instance when creating a subordinate class
instance. Likewise, it can be queried to determine the
superior class instance (if any) for an
existing class instance.
While this object complies with the RFC 1443
InstancePointer textual convention,
it furthermore conforms to the
specifications of IIMCOMIBTRANS
({ iimcManagement 3 1 5 })
subsections 2.13 and 2.14 that
enforce consistency with OSI management
containment relationships, abstract services and
permissible object states."
::= { t1taTroubleReportTableEntry 8 }
t1taTroubleReportNameBinding OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object allows specification of a
specific NAME BINDING for creation of a class
entry instance. It can also be examined to
determine the NAME BINDING in effect for an existing
class table instance.
Use of this object must conform to the specifications
of IIMCOMIBTRANS ({ iimcManagement 3 1 5 })
subsections 2.13 and 2.14 which
enforce consistency with OSI management
containment relationships, abstract services and
permissible object states."
::= { t1taTroubleReportTableEntry 9 }
t1taTroubleReportRowStatus OBJECT-TYPE
Newnan Expires November 29, 1993 Page 69
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object complies with the RowStatus textual
convention of the SNMPv2 framework per RFC 1443.
Behavior of this object furthermore conforms to
subsections 2.13 and 2.14 of IIMCOMIBTRANS
({ iimcManagement 3 1 5 }), that
enforce consistency with OSI management
containment relationships, abstract services and
permissible object states.
These subsections specify constraints (refinements) to
RowStatus usage beyond what is specified by RFC 1443."
::= { t1taTroubleReportTableEntry 10 }
-- *******************************************************
-- The following is a side table because it is translated
-- from a multi-valued attribute:
t1taTroubleReportAccessTimeLocationListTable OBJECT-TYPE
SYNTAX SEQUENCE OF
T1TATroubleReportAccessTimeLocationListTableEntry
MAX-ACCESS not-accessible
STATUS current
-- This attribute is in a conditional package, so it
-- may be absent from a given conceptual row.
DESCRIPTION
"The Access Time Location list attribute identifies the
set or subset of service locations for which the
Location Access Hours attribute values are valid."
REFERENCE "trAttribute 2"
::= { t1taTroubleReportTable 2 }
t1taTroubleReportAccessTimeLocationListTableEntry OBJECT-TYPE
SYNTAX T1TATroubleReportAccessTimeLocationListTableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"t1taTroubleReportAccessTimeLocationListTable entry."
INDEX {
t1taTroubleReportAccessTimeLocationListClassIndex,
t1taTroubleReportAccessTimeLocationListValueIndex
}
::= { t1taTroubleReportAccessTimeLocationListTable 1 }
Newnan Expires November 29, 1993 Page 70
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
T1TATroubleReportAccessTimeLocationListTableEntry
::= SEQUENCE {
t1taTroubleReportAccessTimeLocationListClassIndex
Integer32,
t1taTroubleReportAccessTimeLocationListValueIndex
Integer32,
t1taTroubleReportAccessTimeLocationListPremisesName
DisplayString,
t1taTroubleReportAccessTimeLocationListPremisesAddress
DisplayString,
t1taTroubleReportAccessTimeLocationListRowStatus
RowStatus
}
t1taTroubleReportAccessTimeLocationListClassIndex OBJECT-TYPE
-- side table class index
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Has same value as class entry index of managed object."
::= { t1taTroubleReportAccessTimeLocationListTableEntry 1 }
t1taTroubleReportAccessTimeLocationListValueIndex OBJECT-TYPE
-- side table value index
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Uniquely discriminates a value of
t1taTroubleReportAccessTimeLocationList within a managed
object"
::= { t1taTroubleReportAccessTimeLocationListTableEntry 2 }
t1taTroubleReportAccessTimeLocationListPremisesName
OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The access time for a service location list premises
name."
::= { t1taTroubleReportAccessTimeLocationListTableEntry 30 }
t1taTroubleReportAccessTimeLocationListPremisesAddress
OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
Newnan Expires November 29, 1993 Page 71
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
"The access time for a service location list premises
address."
::= { t1taTroubleReportAccessTimeLocationListTableEntry 4 }
t1taTroubleReportAccessTimeLocationListRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object complies with the RowStatus textual
convention of the SNMPv2 framework per RFC 1443.
Behavior of this object furthermore conforms to
subsections 2.13 and 2.14 of IIMCOMIBTRANS
({ iimcManagement 3 1 5 }), that
enforce consistency with OSI management
containment relationships, abstract services and
permissible object states.
These subsections specify constraints (refinements) to
RowStatus usage beyond what is specified by RFC 1443."
::= { t1taTroubleReportAccessTimeLocationListTableEntry 5 }
-- ******************************************************
t1taTroubleReportChildTable OBJECT-TYPE
SYNTAX SEQUENCE OF T1TATroubleReportChildTableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Allows children in the ISO/CCITT Management naming
hierarchy to be returned."
::= { t1taTroubleReportTable 3 }
t1taTroubleReportChildTableEntry OBJECT-TYPE
SYNTAX T1TATroubleReportChildTableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of Child table."
INDEX {
t1taTroubleReportChildClassIndex,
t1taTroubleReportChildValueIndex
}
::= { t1taTroubleReportChildTable 1 }
Newnan Expires November 29, 1993 Page 72
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
T1TATroubleReportChildTableEntry ::= SEQUENCE {
t1taTroubleReportChildClassIndex Integer32,
t1taTroubleReportChildValueIndex Integer32,
t1taTroubleReportChild InstancePointer
-- RowStatus is not applicable
}
t1taTroubleReportChildClassIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Implicit index value of class table."
::= {t1taTroubleReportChildTableEntry 1}
t1taTroubleReportChildValueIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Implicit index value of child table."
::= {t1taTroubleReportChildTableEntry 2}
t1taTroubleReportChild OBJECT-TYPE
SYNTAX InstancePointer
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This parameter is typically used in conjunction with a
get next operation to acquire class InstancePointers for
successive child (contained) objects within the parent.
This object complies with the RFC 1443 InstancePointer
textual convention of the SNMPv2 framework, which
defines an OBJECT IDENTIFIER pointer to a conceptual
row.
Behavior of this object furthermore conforms to the
specifications of IIMCOMIBTRANS
({ iimcManagement 3 1 5 })
subsections 2.13 and 2.14 that
enforce consistency with OSI management
containment relationships, abstract services and
permissible object states."
::= {t1taTroubleReportChildTableEntry 3 }
END
Newnan Expires November 29, 1993 Page 73
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Newnan Expires November 29, 1993 Page 74
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Appendix B (Normative): Definition of Management Information
This appendix has two parts.
(1) Section B.1 explains how (to what extent) standard
Definition of Management Information [ISO10165-2]
notifications can be mapped into SNMP traps.
(2) Sections B.2 and B.3 provide translated ASN.1 definitions
representing [ISO10165-2] notifications, for use with SNMPv1
and SNMPv2, respectively.
B.1. Notes on ISO/CCITT DMI Translation
This subsection documents the translation of DMI notifications
to traps per steps described in subsection 2.12.
The decisions per step (1) are to select the output subtrees
onSMI2toInternetNotification and onSMI2toInternetAttributeID,
and the prefix "on".
Table B-1 reflects the listing of notifications per the
procedures of step (2). The abbreviations used for mandatory
attributes in this table are defined in Table B-2.
Table B-2 itself provides the mapping of ISO/CCITT syntaxes to
fixed and scalar types per step (3). This illustrates the
complexity of the problem and need for human judgment.
Newnan Expires November 29, 1993 Page 75
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
--------------------------------------------------------
arc notification syntax mandatory
attributes
--------------------------------------------------------
1 attributeValue- AttributeValue- avci
Change ChangeInfo
2 communicationsAlarm AlarmInfo pc,ps
3 environmentalAlarm AlarmInfo pc,ps
4 equipmentAlarm AlarmInfo pc,ps
5 integrityViolation SecurityAlarmInfo sac,sas,sad,
su,spv
6 objectCreation ObjectInfo (none)
7 objectDeletion ObjectInfo (none)
8 operational- SecurityAlarmInfo sac,sas,sad,
Violation su,spv
9 physicalViolation SecurityAlarmInfo sac,sas,sad,
su,spv
10 processingErrorAlarm AlarmInfo pc,ps
11 qualityOfServiceAlarm AlarmInfo pc,ps
12 relationshipChange Relationship- rcd
ChangeInfo
13 securityServiceOr- SecurityAlarmInfo sac,sas,sad,
MechanismViolation su,spv
14 stateChange StateChangeInfo scd
15 timeDomainViolation SecurityAlarmInfo sac,sas,sad,
su,spv
-------------------------------------------------
Figure B-1. DMI Notifications
Newnan Expires November 29, 1993 Page 76
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
-------------------------------------------------
arc abbreviation
attribute identifier/syntax resolves to
-------------------------------------------------
10 avci
attributeValueChangeDefinition/AttributeValueChangeDefinition
18 pc
probableCause/ProbableCause
17 ps
perceivedSeverity/PerceivedSeverity
20 rcd
relationshipChangeDefinition/AttributeValueChangeDefinition
21 sac
securityAlarmCause/ProbableCause
22 sad
securityAlarmDetector/SecurityAlarmDetector
23 sas
securityAlarmSeverity/SecurityAlarmSeverity
28 scd
stateChangeDefinition/AttributeValueChangeDefinitiion
24 spv
serviceProvider/ServiceUser
25 su
serviceUser/ServiceUser
-------------------------------------------------
Figure B-2. Mandatory Attributes
The latter half of subsection B.2 provides the output of steps
(4) and (5).
Newnan Expires November 29, 1993 Page 77
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
--------------------------------------------------------
The format of this table is as follows:
< identifier > ::= < OSI Syntax >
=> < resulting SNMP Syntax >
[Comments]
--------------------------------------------------------
AttributeValueChangeDefinition::=SET OF SEQUENCE {
attributeID AttributeId,
oldAttributeValue
[1] ANY DEFINED BY attributeID OPTIONAL,
newAttributeValue [2] ANY DEFINED BY attributeID}
=> OBJECT IDENTIFIER
[Maps to OBJECT IDENTIFIER for conceptual row of ATTRIBUTE
within class table or of side table. The oldAttributeValue is
optional thus not supported. The new value can be gotten
through polling.]
--------------------------------------------------------
PerceivedSeverity ::= ENUMERATED{ indeterminate(0), critical
(1), major (2), minor (3), warning (4), cleared (5) }
=> INTEGER
[Enumerated values are carried over except that zero maps to
32767.]
--------------------------------------------------------
ProbableCause ::= CHOICE {
globalValue OBJECT IDENTIFIER,
localValue INTEGER}
=> OBJECT IDENTIFIER
[The localValue is option is supported by suffixing the
integer value to the special OBJECT IDENTIFIER,
onSMI2toInternetIntegerForm.]
--------------------------------------------------------
SecurityAlarmDetector::= CHOICE {
mechanism [0] OBJECT IDENTIFIER,
object [1] ObjectInstance,
application [2] AE-title}
=> OBJECT IDENTIFIER
[ObjectInstance maps to OID (class InstancePointer ) and
mechanism OID is passed through unaltered; there is no
ambiguity between the two. AE Title is an alien construct to
the internet community. This option should be supported via
an empty OID and descriptive text in the
ocAdditionalInformation variable.]
--------------------------------------------------------
ServiceUser ::= SEQUENCE {
identifier OBJECT IDENTIFIER,
details ANY DEFINED BY identifier }
=> DisplayString
[ANYs are deprecated for SNMP. A text string provides a
reasonable way to map this general notion.]
------------------------------------------------
Figure B-3. Mapping of ISO/CCITT Syntaxes to Scalars
Newnan Expires November 29, 1993 Page 78
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
B.2. SNMPv1 Translation of DMI
MIBosidmiSNMPv1 DEFINITIONS ::= BEGIN
IMPORTS
iimcOMIBTRANS FROM IimcAssignedOIDs
OBJECT-TYPE FROM RFC1155-SMI;
-- *******************************************************
-- OBJECT IDENTIFIERS
-- *******************************************************
-- Objects defined within this module are assigned beneath
-- the following arc:
osidmi OBJECT IDENTIFIER ::= { iimcOMIBTRANS 2 }
-- Separate arcs are assigned beneath this arc for
-- TRAP-TYPES and their support objects:
osidmiNotifications OBJECT IDENTIFIER ::= { osidmi 1 }
osidmiAttributes OBJECT IDENTIFIER ::= { osidmi 2 }
-- The following prefix is used to deal with the situation
-- where OSI syntax allows a choice of INTEGER or OBJECT
-- IDENTIFIER. The SNMP mapping is to OBJECT IDENTIFIER.
-- The integer option is also mapped to OBJECT IDENTIFIER
-- by concatentating the values of osidmiIntegerChoice
-- (defined below) and then the integer in question. The
-- result is passed as the value of the VARIABLES clause.
osidmiIntegerChoice OBJECT IDENTIFIER ::= { osidmi 3 }
-- The registration of this ASN.1 module is:
-- { osidmi 0 1 }
-- *******************************************************
-- This module contains:
-- * TRAP-TYPE definitions corresponding to the OSI
-- Definition of Management Information (DMI)
-- NOTIFICATIONs.
-- * Supporting OBJECT-TYPEs to be referenced in the
-- VARIABLES clauses of these traps. Those objects
-- correspond to the mandatory ATTRIBUTES of the
-- associated NOTIFICATIONS.
-- *******************************************************
-- Following are SNMPv1 mappings of the standard DMI
Newnan Expires November 29, 1993 Page 79
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
-- NOTIFICATIONS. Each of these traps and OBJECT-TYPES
-- may be implemented independent of the others.
-- It is recommended these mappings to traps be used
-- very sparingly. Where their use
-- is necessary, the following "standard"
-- traps be used where applicable:
osidmiAttributeValueChange TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiAttributeValueChangeDefinition
}
DESCRIPTION
"This notification type is used to report changes
to the attribute such as addition or deletion of
members to one or more set valued attributes,
replacement of the value of one or more attributes
and setting attribute values to their defaults."
REFERENCE "ISO 10165-2: smi2Notification 1"
::= 1
osidmiCommunicationsAlarm TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiProbableCause,
osidmiPerceivedSeverity
}
DESCRIPTION
"This notification type is used to report when the
object detects a communications error."
REFERENCE "ISO 10165-2: smi2Notification 2"
::= 2
osidmiEnvironmentalAlarm TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiProbableCause,
osidmiPerceivedSeverity
}
DESCRIPTION
"This notification type is used to report a
problem in the environment."
Newnan Expires November 29, 1993 Page 80
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
REFERENCE "ISO 10165-2: smi2Notification 3"
::= 3
osidmiEquipmentAlarm TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiProbableCause,
osidmiPerceivedSeverity
}
DESCRIPTION
"This notification type is used to report a
failure in the equipment."
REFERENCE "ISO 10165-2: smi2Notification 4"
::= 4
osidmiIntegrityViolation TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiSecurityAlarmCause,
osidmiSecurityAlarmDetector,
osidmiSecurityAlarmSeverity,
osidmiServiceProvider,
osidmiServiceUser
}
DESCRIPTION
"This notification is used to report that a
potential interruption in information flow
has occurred such that information may have been
illegally modified, inserted or deleted"
REFERENCE "ISO 10165-2: smi2Notification 5"
::= 5
osidmiObjectCreation TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES{
osidmiManagedObjectInstance,
osidmiAdditionalText
}
DESCRIPTION
"This notification type is used to report the
creation of a managed object to another
open system."
REFERENCE "ISO 10165-2: smi2Notification 6"
Newnan Expires November 29, 1993 Page 81
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
::= 6
osidmiObjectDeletion TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES{
osidmiManagedObjectInstance,
osidmiAdditionalText
}
DESCRIPTION
"This notification type is used to report the
deletion of a managed object to another
open system."
REFERENCE "ISO 10165-2: smi2Notification 7"
::= 7
osidmiOperationalViolation TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiSecurityAlarmCause,
osidmiSecurityAlarmDetector,
osidmiSecurityAlarmSeverity,
osidmiServiceProvider,
osidmiServiceUser
}
DESCRIPTION
"This notification is used to report that the
provision of the requested service was not
possible due to the unavailability, malfunction or
incorrect invocation of the service"
REFERENCE "ISO 10165-2: smi2Notification 8"
::= 8
osidmiPhysicalViolation TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiSecurityAlarmCause,
osidmiSecurityAlarmDetector,
osidmiSecurityAlarmSeverity,
osidmiServiceProvider,
osidmiServiceUser
}
DESCRIPTION
"This notification is used to report that a
physical resource has been violated in a way
that indicates a potential security attack"
Newnan Expires November 29, 1993 Page 82
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
REFERENCE "ISO 10165-2: smi2Notification 9"
::= 9
osidmiProcessingErrorAlarm TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiProbableCause,
osidmiPerceivedSeverity
}
DESCRIPTION
"This notification type is used to report processing
failure in a managed object."
REFERENCE "ISO 10165-2: smi2Notification 10"
::= 10
osidmiQualityOfServiceAlarm TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiProbableCause,
osidmiPerceivedSeverity
}
DESCRIPTION
"This notification type is used to report a failure
in the quality of service of the managed object."
REFERENCE "ISO 10165-2: smi2Notification 11"
::= 11
osidmiRelationshipChange TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiRelationshipChangeDefinition
}
DESCRIPTION
"This notification type is used to report
the change in the value of a relationship
attributes of a managed object, that result
through either internal operation of the managed object
or via management operation."
-- This is a subset of ISO/CCITT functionality and
-- has been edited accordingly.
REFERENCE "ISO 10165-2: smi2Notification 12"
Newnan Expires November 29, 1993 Page 83
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
::= 12
osidmiSecurityServiceOrMechanismViolation TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiSecurityAlarmCause,
osidmiSecurityAlarmDetector,
osidmiSecurityAlarmSeverity,
osidmiServiceProvider,
osidmiServiceUser
}
DESCRIPTION
"This notification is used to report that a
security attack has been detected by a security service
or mechanism"
REFERENCE "ISO 10165-2: smi2Notification 13"
::= 13
osidmiStateChange TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiStateChangeDefinition
}
DESCRIPTION
"This notification type is used to report the change in
the value of a state attribute of a managed
object, that result through either internal operation of
the managed object or via management operation."
-- This is a subset of ISO/CCITT functionality and
-- the description accordingly has been manually
-- edited.
REFERENCE "ISO 10165-2: smi2Notification 14"
::= 14
osidmiTimeDomainViolation TRAP-TYPE
ENTERPRISE osidmiNotifications
VARIABLES {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiSecurityAlarmCause,
osidmiSecurityAlarmDetector,
osidmiSecurityAlarmSeverity,
osidmiServiceProvider,
osidmiServiceUser
}
Newnan Expires November 29, 1993 Page 84
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
DESCRIPTION
"This notification is used to report that an
event has occurred at an unexpected or prohibited time."
REFERENCE "ISO 10165-2: smi2Notification 15"
::= 15
-- *******************************************************
-- The following objects are not accessible and exist only
-- for purposes of mapping ISO/CCITT
-- DMI attributes to the VARIABLES of traps.
-- These objects map several kinds of DMI ATTRIBUTEs
-- relating to NOTIFICATIONs:
-- Every DMI ATTRIBUTE that is mandatory for some
-- NOTIFICATION.
-- The managedObjectInstance ATTRIBUTE,
-- which is always provided by CMIP.
-- ATTRIBUTE additionalText, which is listed in the
-- VARIABLES parameter for all translated
-- NOTIFICATIONs, even though it is generally optional
-- in ISO/CCITT usage. This allows additional
-- information to be conveyed that might otherwise
-- be lost when translating to SNMP
-- In the DESCRIPTION clauses of these objects, the term
-- "attribute" is used synonomously with corresponding
-- SNMP trap VARIABLEs.
osidmiAdditionalText OBJECT-TYPE
SYNTAX OCTET STRING -- OSI GraphicString
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This attribute is used to specify additional
textual information in NOTIFICATIONs "
REFERENCE "ISO 10165-2: smi2AttributeID 7"
::= {osidmiAttributes 7}
osidmiAttributeValueChangeDefinition OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This attribute contains the OBJECT IDENTIFIER of
an ATTRIBUTE whose change has been detected."
-- This is a subset of ISO/CCITT functionality, as
Newnan Expires November 29, 1993 Page 85
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
-- discussed in the informational part of this annex.
-- The description clause is therefore entered manually
-- rather than copied verbatim.
REFERENCE "ISO 10165-2: smi2AttributeID 10"
::= {osidmiAttributes 10}
osidmiPerceivedSeverity OBJECT-TYPE
SYNTAX INTEGER
-- indeterminate (32767), critical (1), major (2),
-- minor (3), warning (4), cleared (5)
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Reflects severity of an alarm as perceived by that
entity or service detecting it."
-- no ISO/CCITT BEHAVIOR description exists
REFERENCE "ISO 10165-2: smi2AttributeID 17"
::= {osidmiAttributes 17}
osidmiProbableCause OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Reflects the probable cause of an alarm as perceived by
the entity or service detecting it."
-- no ISO/CCITT BEHAVIOR description exists
-- defined in ISO 10164-4
REFERENCE "ISO 10165-2: smi2AttributeID 18"
::= {osidmiAttributes 18}
osidmiRelationshipChangeDefinition OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This attribute provides the OBJECT IDENTIFIER for
a relationship ATTRIBUTE that has changed."
-- This is a subset of ISO/CCITT functionality, as
-- discussed in the informational part of this annex.
-- The description clause is therefore entered manually
-- rather than copied verbatim.
REFERENCE "ISO 10165-2: smi2AttributeID 20"
::= {osidmiAttributes 20}
osidmiSecurityAlarmCause OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
Newnan Expires November 29, 1993 Page 86
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This attribute specifies the cause of the
security alarm"
REFERENCE "ISO 10165-2: smi2AttributeID 21"
::= {osidmiAttributes 21}
osidmiSecurityAlarmDetector OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This attribute identifies the entity that
detected the security alarm"
REFERENCE "ISO 10165-2: smi2AttributeID 22"
::= {osidmiAttributes 22}
osidmiSecurityAlarmSeverity OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This attribute indicates the severity of the
security alarm"
REFERENCE "ISO 10165-2: smi2AttributeID 23"
::= {osidmiAttributes 23}
osidmiServiceProvider OBJECT-TYPE
SYNTAX DisplayString
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This attribute contains information about the
service provider associated with the service request
that caused the security alarm"
REFERENCE "ISO 10165-2: smi2AttributeID 24"
::= {osidmiAttributes 24}
osidmiServiceUser OBJECT-TYPE
SYNTAX DisplayString
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This attribute contains information about the
Newnan Expires November 29, 1993 Page 87
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
service user associated with the service request that
caused the security alarm"
REFERENCE "ISO 10165-2: smi2AttributeID 25"
::= {osidmiAttributes 25}
osidmiStateChangeDefinition OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This attribute contains the OBJECT IDENTIFIER of
a state ATTRIBUTE that has changed."
-- This is a subset of ISO/CCITT functionality, as
-- discussed in the informational part of this annex.
-- The description clause is therefore entered manually
-- rather than copied verbatim.
REFERENCE "ISO 10165-2: smi2AttributeID 28"
::= {osidmiAttributes 28}
osidmiManagedObjectInstance OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER -- class InstancePointer
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Provides the class InstancePointer (managed object
instance) of the object issuing the notification.
This is used in lieu of the CMIP ManagedObjectClass
and ManagedObjectInstance parameters."
REFERENCE "ISO 10165-2: smi2AttributeID 61"
::= {osidmiAttributes 61}
END
Newnan Expires November 29, 1993 Page 88
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
B.3. SNMPv2 Translation of DMI
MIBosidmiSNMPv2 DEFINITIONS ::= BEGIN
IMPORTS
iimcOMIBTRANS
FROM IimcAssignedOIDs
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Integer32, internet, snmpModules
FROM SNMPv2-SMI
TruthValue, DisplayString, TimeStamp
FROM SNMPv2-TC
-- GraphicString
-- FROM IIMComibtransSptSNMPv2
OBJECT-GROUP FROM SNMPv2-CONF;
osidmiSNMPv2 MODULE-IDENTITY
LAST-UPDATED "9305250000Z"
ORGANIZATION "Network Management Forum"
CONTACT-INFO
"Owen Newnan * U S WEST Advanced Technologies
4001 Discovery Avenue Suite 190
Boulder, CO 80303
303 541-6253 fax x6250 * onewnan@advtech.uswest.com"
DESCRIPTION
"Facilitates mechanized translation of MIBs from ISO
GDMO to SNMPv2 SMI format."
::= { onSMI2toInternetConvergenceMIB 1 }
-- *******************************************************
-- OBJECT IDENTIFIERS
-- *******************************************************
-- Objects defined within this module are assigned beneath
-- the following arc:
osidmi OBJECT IDENTIFIER ::= { iimcOMIBTRANS 2 }
-- Separate arcs are assigned beneath this arc for
-- TRAP-TYPES and their support objects:
osidmiNotifications OBJECT IDENTIFIER ::= { osidmi 1 }
osidmiAttributes OBJECT IDENTIFIER ::= { osidmi 2 }
-- The following prefix is used to deal with the situation
-- where OSI syntax allows a choice of INTEGER or OBJECT
-- IDENTIFIER. The SNMP mapping is to OBJECT IDENTIFIER.
-- The integer option is also mapped to OBJECT IDENTIFIER
Newnan Expires November 29, 1993 Page 89
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
-- by concatentating the values of osidmiIntegerChoice
-- (defined below) and then the integer in question. The
-- result is passed as the value of the VARIABLES clause.
osidmiIntegerChoice OBJECT IDENTIFIER ::= { osidmi 3 }
-- The registration of this ASN.1 module is:
-- { osidmi 0 2 }
-- *******************************************************
-- This module contains:
-- * NOTIFICATION-TYPE definitions corresponding to the
-- Definition of Management Information (DMI)
-- NOTIFICATIONs.
-- * Supporting OBJECT-TYPEs to be referenced in the
-- OBJECTS clauses of these notifications. Those
-- objects correspond to the mandatory ATTRIBUTES of
-- the associated NOTIFICATIONS.
-- *******************************************************
-- Following are SNMPv2 mappings of the standard DMI
-- NOTIFICATIONSs. Each of these traps and OBJECT-TYPES
-- may be implemented independent of the others.
-- It is recommended these mappings to traps be used
-- very sparingly. Where their use
-- is necessary, the following "standard"
-- traps be used where applicable:
osidmiAttributeValueChange NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiAttributeValueChangeDefinition
}
STATUS current
DESCRIPTION
"This notification type is used to report changes
to the attribute such as addition or deletion of
members to one or more set valued attributes,
replacement of the value of one or more attributes
and setting attribute values to their defaults."
REFERENCE "ISO 10165-2: smi2Notification 1"
::= { osidmiNotification 1 }
osidmiCommunicationsAlarm NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
Newnan Expires November 29, 1993 Page 90
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
osidmiAdditionalText,
osidmiProbableCause,
osidmiPerceivedSeverity
}
STATUS current
DESCRIPTION
"This notification type is used to report when the
object detects a communications error."
REFERENCE "ISO 10165-2: smi2Notification 2"
::= { osidmiNotification 2 }
osidmiEnvironmentalAlarm NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiProbableCause,
osidmiPerceivedSeverity
}
STATUS current
DESCRIPTION
"This notification type is used to report a
problem in the environment."
REFERENCE "ISO 10165-2: smi2Notification 3"
::= { osidmiNotification 3 }
osidmiEquipmentAlarm NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiProbableCause,
osidmiPerceivedSeverity
}
STATUS current
DESCRIPTION
"This notification type is used to report a
failure in the equipment."
REFERENCE "ISO 10165-2: smi2Notification 4"
::= { osidmiNotification 4 }
osidmiIntegrityViolation NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiSecurityAlarmCause,
osidmiSecurityAlarmDetector,
osidmiSecurityAlarmSeverity,
osidmiServiceProvider,
osidmiServiceUser
}
STATUS current
Newnan Expires November 29, 1993 Page 91
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
DESCRIPTION
"This notification is used to report that a
potential interruption in information flow
has occurred such that information may have been
illegally modified, inserted or deleted"
REFERENCE "ISO 10165-2: smi2Notification 5"
::= { osidmiNotification 5 }
osidmiObjectCreation NOTIFICATION-TYPE
OBJECTS{
osidmiManagedObjectInstance,
osidmiAdditionalText
}
STATUS current
DESCRIPTION
"This notification type is used to report the
creation of a managed object to another
open system."
REFERENCE "ISO 10165-2: smi2Notification 6"
::= { osidmiNotification 6 }
osidmiObjectDeletion NOTIFICATION-TYPE
OBJECTS{
osidmiManagedObjectInstance,
osidmiAdditionalText
}
STATUS current
DESCRIPTION
"This notification type is used to report the
deletion of a managed object to another
open system."
REFERENCE "ISO 10165-2: smi2Notification 7"
::= { osidmiNotification 7 }
osidmiOperationalViolation NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiSecurityAlarmCause,
osidmiSecurityAlarmDetector,
osidmiSecurityAlarmSeverity,
osidmiServiceProvider,
osidmiServiceUser
}
STATUS current
DESCRIPTION
"This notification is used to report that the
Newnan Expires November 29, 1993 Page 92
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
provision of the requested service was not
possible due to the unavailability, malfunction or
incorrect invocation of the service"
REFERENCE "ISO 10165-2: smi2Notification 8"
::= { osidmiNotification 8 }
osidmiPhysicalViolation NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiSecurityAlarmCause,
osidmiSecurityAlarmDetector,
osidmiSecurityAlarmSeverity,
osidmiServiceProvider,
osidmiServiceUser
}
STATUS current
DESCRIPTION
"This notification is used to report that a
physical resource has been violated in a way
that indicates a potential security attack"
REFERENCE "ISO 10165-2: smi2Notification 9"
::= { osidmiNotification 9 }
osidmiProcessingErrorAlarm NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiProbableCause,
osidmiPerceivedSeverity
}
STATUS current
DESCRIPTION
"This notification type is used to report processing
failure in a managed object."
REFERENCE "ISO 10165-2: smi2Notification 10"
::= { osidmiNotification 10 }
osidmiQualityOfServiceAlarm NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiProbableCause,
osidmiPerceivedSeverity
}
STATUS current
DESCRIPTION
"This notification type is used to report a failure
Newnan Expires November 29, 1993 Page 93
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
in the quality of service of the managed object."
REFERENCE "ISO 10165-2: smi2Notification 11"
::= { osidmiNotification 11 }
osidmiRelationshipChange NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiRelationshipChangeDefinition
}
STATUS current
DESCRIPTION
"This notification type is used to report
the change in the value of a relationship
attributes of a managed object, that result
through either internal operation of the managed object
or via management operation."
-- This is a subset of ISO/CCITT functionality and
-- has been edited accordingly.
REFERENCE "ISO 10165-2: smi2Notification 12"
::= { osidmiNotification 12 }
osidmiSecurityServiceOrMechanismViolation NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiSecurityAlarmCause,
osidmiSecurityAlarmDetector,
osidmiSecurityAlarmSeverity,
osidmiServiceProvider,
osidmiServiceUser
}
STATUS current
DESCRIPTION
"This notification is used to report that a
security attack has been detected by a security service
or mechanism"
REFERENCE "ISO 10165-2: smi2Notification 13"
::= { osidmiNotification 13 }
osidmiStateChange NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiStateChangeDefinition
}
STATUS current
DESCRIPTION
Newnan Expires November 29, 1993 Page 94
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
"This notification type is used to report the change in
the value of a state attribute of a managed
object, that result through either internal operation of
the managed object or via management operation."
-- This is a subset of ISO/CCITT functionality and
-- the description accordingly has been manually
-- edited.
REFERENCE "ISO 10165-2: smi2Notification 14"
::= { osidmiNotification 14 }
osidmiTimeDomainViolation NOTIFICATION-TYPE
OBJECTS {
osidmiManagedObjectInstance,
osidmiAdditionalText,
osidmiSecurityAlarmCause,
osidmiSecurityAlarmDetector,
osidmiSecurityAlarmSeverity,
osidmiServiceProvider,
osidmiServiceUser
}
STATUS current
DESCRIPTION
"This notification is used to report that an
event has occurred at an unexpected or prohibited time"
REFERENCE "ISO 10165-2: smi2Notification 15"
::= { osidmiNotification 15 }
-- *******************************************************
-- The following objects are not accessible and exist only
-- for purposes of mapping ISO/CCITT
-- DMI attributes to the OBJECTS of traps.
-- These objects map several kinds of DMI ATTRIBUTEs
-- relating to NOTIFICATIONs:
-- Every DMI ATTRIBUTE that is mandatory for some
-- NOTIFICATION.
-- ATTRIBUTEs eventTime and managedObjectInstance,
-- which are always provided by CMIP.
-- ATTRIBUTE additionalText, which is listed in the
-- OBJECTS parameter for all translated
-- NOTIFICATIONs, even though it is generally optional
-- in ISO/CCITT usage. This allows additional
-- information to be conveyed that might otherwise
-- be lost when translating to SNMP
-- In the DESCRIPTION clauses of these objects, the term
-- "attribute" is used synonomously with corresponding
Newnan Expires November 29, 1993 Page 95
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
-- SNMP trap OBJECTS.
osidmiAdditionalText OBJECT-TYPE
SYNTAX GraphicString
-- [Editor's note: should this be OCTET STRING?
-- The ISO form is GraphicString.]
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This attribute is used to specify additional
textual information in NOTIFICATIONs "
REFERENCE "ISO 10165-2: smi2AttributeID 7"
::= {osidmiAttribute 7}
osidmiAttributeValueChangeDefinition OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This attribute contains the OBJECT IDENTIFIER of
an ATTRIBUTE whose change has been detected."
-- This is a subset of ISO/CCITT functionality, as
-- discussed in the informational part of this annex.
-- The description clause is therefore entered manually
-- rather than copied verbatim.
REFERENCE "ISO 10165-2: smi2AttributeID 10"
::= {osidmiAttribute 10}
osidmiPerceivedSeverity OBJECT-TYPE
SYNTAX Integer32
-- indeterminate (32767), critical (1), major (2),
-- minor (3), warning (4), cleared (5)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Reflects the severity of an alarm as perceived by the
entity or service that detected it."
-- no ISO/CCITT BEHAVIOR description exists
REFERENCE "ISO 10165-2: smi2AttributeID 17"
::= {osidmiAttribute 17}
osidmiProbableCause OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Reflects the probable casue of an alarm as perceived by
Newnan Expires November 29, 1993 Page 96
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
the entity or service that detected it."
-- no ISO/CCITT BEHAVIOR description exists
-- defined in ISO 10164-4
REFERENCE "ISO 10165-2: smi2AttributeID 18"
::= {osidmiAttribute 18}
osidmiRelationshipChangeDefinition OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This attribute provides the OBJECT IDENTIFIER for
a relationship ATTRIBUTE that has changed."
-- This is a subset of ISO/CCITT functionality, as
-- discussed in the informational part of this annex.
-- The description clause is therefore entered manually
-- rather than copied verbatim.
REFERENCE "ISO 10165-2: smi2AttributeID 20"
::= {osidmiAttribute 20}
osidmiSecurityAlarmCause OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This attribute specifies the cause of the
security alarm"
REFERENCE "ISO 10165-2: smi2AttributeID 21"
::= {osidmiAttribute 21}
osidmiSecurityAlarmDetector OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This attribute identifies the entity that
detected the security alarm"
REFERENCE "ISO 10165-2: smi2AttributeID 22"
::= {osidmiAttribute 22}
osidmiSecurityAlarmSeverity OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This attribute indicates the severity of the
Newnan Expires November 29, 1993 Page 97
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
security alarm"
REFERENCE "ISO 10165-2: smi2AttributeID 23"
::= {osidmiAttribute 23}
osidmiServiceProvider OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This attribute contains information about the
service provider associated with the service request
that caused the security alarm"
REFERENCE "ISO 10165-2: smi2AttributeID 24"
::= {osidmiAttribute 24}
osidmiServiceUser OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This attribute contains information about the
service user associated with the service request that
caused the security alarm"
REFERENCE "ISO 10165-2: smi2AttributeID 25"
::= {osidmiAttribute 25}
osidmiStateChangeDefinition OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This attribute contains the OBJECT IDENTIFIER of
a state ATTRIBUTE that has changed."
-- This is a subset of ISO/CCITT functionality, as
-- discussed in the informational part of this annex.
-- The description clause is therefore entered manually
-- rather than copied verbatim.
REFERENCE "ISO 10165-2: smi2AttributeID 28"
::= {osidmiAttribute 28}
osidmiManagedObjectInstance OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER -- class InstancePointer
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Provides the class InstancePointer (managed object
Newnan Expires November 29, 1993 Page 98
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
instance) of the object issuing the notification.
This is used in lieu of the CMIP ManagedObjectClass
and ManagedObjectInstance parameters."
REFERENCE "ISO 10165-2: smi2AttributeID 61"
::= {osidmiAttribute 61}
END
Newnan Expires November 29, 1993 Page 99
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
Appendix C (Normative): Support Objects For Use With
Translated MIBs
This Appendix provides supporting MIB specifications to assist
in the use of translated OSI MIB constructs. These
specifications are:
(1) the omibtransSptNextUniqueTable, an optional table that
allows an agent to allocate indices for row creation on a per-
table basis,
(2) the omibtransSptTrapSuppressionTable, which allows traps
to be suppressed or enabled on a per TRAP-TYPE basis, and
(3) graphicString, an SNMPv2 textual convention for this
commonly-used ASN.1 type.
Items (1) and (2) are provided for use with both SNMPv1 and
SNMPv2; Item (3) is provided only for use with SNMPv2.
This document (IIMCOMIBTRANS) is allocated the following
registration identifier for purposes of referencing material
contained herein.
iimcOMIBTRANS OBJECT IDENTIFIER ::= { iimcManagementDocMan 5}
This document further allocates registration identifiers to
the two MIBs currently specified within Appendix B and
Appendix C of this document:
osidmi OBJECT IDENTIFIER ::= { iimcOMIBTRANS 1 }
omibtransSpt OBJECT IDENTIFIER ::= { iimcOMIBTRANS 2 }
Editor's Note: [Reader comment is requested how best to
structure objects registered by the NM Forum that support or
comply with the translation procedures of this document,
considering that compact OBJECT IDENTIFIERs are especially
important for SNMP usage.]
C.1 SNMPv1 Support Objects
IIMComibtransSptSNMPv1 DEFINITIONS ::= BEGIN
IMPORTS
iimcOMIBTRANS FROM IimcAssignedOIDs
OBJECT-TYPE, internet FROM RFC1155-SMI;
-- Objects defined within this module are assigned beneath
-- the following arc:
Newnan Expires November 29, 1993 Page
100
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
omibtransSpt OBJECT IDENTIFIER ::= { iimcOMIBTRANS 1 }
-- The registration of this ASN.1 module is:
-- { omibtransSpt 0 1 }
-- *******************************************************
--
-- This module contains:
--
-- * A table to allocate indexes which a management
-- station can use to create conceptual rows.
--
-- * A table to selectively suppress issuance of traps.
--
-- *******************************************************
omibtransSptNextUniqueIndexTable OBJECT-TYPE
SYNTAX SEQUENCE OF OmibtransSptNextUniqueIndexEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Provides a class table or side table index for purposes
of manager-initiated creation of rows in tables (i.e.,
new managed object instances or new values
for multi-valued attributes). Successive reads to this
table return different values that are unique within the
scope of the table within that agent. Such values are
assigned arbitrarily by the agent, so a manager should
make no assumption about the sequence or magnitude of
values returned."
::= { omibtransSpt 1 }
omibtransSptNextUniqueIndexEntry OBJECT-TYPE
SYNTAX OmibtransSptNextUniqueIndexEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entry of omibtransSptNextUniqueIndexTable."
INDEX { omibtransSptNextUniqueIndexIndex }
::= { omibtransSptNextUniqueIndexTable 1 }
OmibtransSptNextUniqueIndexEntry ::=
SEQUENCE {
omibtransSptNextUniqueIndexIndex
OBJECT IDENTIFIER,
omibtransSptNextUniqueIndex
INTEGER
}
Newnan Expires November 29, 1993 Page
101
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
omibtransSptNextUniqueIndexIndex OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Provides a prefix indicating the type of conceptual row
to be created by a management station."
::= { omibtransSptNextUniqueIndexEntry 1 }
omibtransSptNextUniqueIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Returns the next index to be used for creation of a
conceptual row in the indicated table. This object
typically returns a different value each time it is
read."
::= { omibtransSptNextUniqueIndexEntry 2 }
-- *******************************************************
omibtransSptTrapSuppressionTable OBJECT-TYPE
SYNTAX SEQUENCE OF OmibtransSptTrapSuppressionEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Provides a means to selectively suppress issuance of
traps under the SNMPv1 framework."
::= { omibtransSpt 2 }
omibtransSptTrapSuppressionEntry OBJECT-TYPE
SYNTAX OmibtransSptTrapSuppressionEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entry of omibtransSptTrapSuppressionTable."
INDEX {
omibtransSptTrapSuppressionEnterprise,
omibtransSptTrapSuppressionTrapNumber
}
::= { omibtransSptTrapSuppressionTable 1 }
OmibtransSptTrapSuppressionEntry ::=
Newnan Expires November 29, 1993 Page
102
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
SEQUENCE {
omibtransSptTrapSuppressionEnterprise
OBJECT IDENTIFIER,
omibtransSptTrapSuppressionTrapNumber
INTEGER,
omibtransSptTrapSuppressionFlag
INTEGER
}
omibtransSptTrapSuppressionEnterprise OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Supplies the Enterprise OBJECT IDENTIFIER for the
trap of interest."
::= { omibtransSptTrapSuppressionEntry 1 }
omibtransSptTrapSuppressionTrapNumber OBJECT-TYPE
SYNTAX INTEGER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Supplies the trap number (value of the TRAP-TYPE macro)
for the trap of interest."
::= { omibtransSptTrapSuppressionEntry 2 }
omibtransSptTrapSuppressionFlag OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object determines whether traps of a given type
will be issued or not.
This object complies with the TruthValue textual
convention of the SNMPv2 framework per RFC 1443.
Thus it is functionally equivalent to a BOOLEAN type but
assumes different values, i.e., false(1) or true(2).
A value of true indicates a trap of the given type shall
be suppressed."
::= { omibtransSptTrapSuppressionEntry 3 }
END
Newnan Expires November 29, 1993 Page
103
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
C.2 SNMPv2 Support Objects
IIMComibtransSptSNMPv2 DEFINITIONS ::= BEGIN
IMPORTS
iimcOMIBTRANS
FROM IimcAssignedOIDs
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Integer32, internet, snmpModules
FROM SNMPv2-SMI
TruthValue, DisplayString, TimeStamp
FROM SNMPv2-TC
OBJECT-GROUP FROM SNMPv2-CONF;
iimcomibtransSptSNMPv2 MODULE-IDENTITY
LAST-UPDATED "9305250000Z"
ORGANIZATION "Network Management Forum"
CONTACT-INFO
"Owen Newnan * U S WEST Advanced Technologies
4001 Discovery Avenue Suite 190
Boulder, CO 80303
303 541-6253 fax x6250 * onewnan@advtech.uswest.com"
DESCRIPTION
"Facilitates mechanized translation of MIBs from OSI
GDMO to the SNMPv1 and SNMPv2 frameworks."
::= { omibtransSpt 0 2 }
-- *******************************************************
-- OBJECT IDENTIFIERS
-- *******************************************************
-- Objects defined within this module are assigned beneath
-- the following arc:
omibtransSpt OBJECT IDENTIFIER ::= { iimcOMIBTRANS 1 }
-- The registration of this ASN.1 module is:
-- { omibtransSpt 0 2 }
-- *******************************************************
-- This module contains:
-- * A table to allocate indexes which a management
-- station can use to create conceptual rows.
-- * A textual convention corresponding to the OSI
-- GraphicString type.
Newnan Expires November 29, 1993 Page
104
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
-- *******************************************************
omibtransSptNextUniqueIndexTable OBJECT-TYPE
SYNTAX SEQUENCE OF OmibtransSptNextUniqueIndexEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Provides a class table or side table index for purposes
of manager-initiated creation of rows in tables (i.e.,
new managed object instances or new values
for multi-valued attributes). Successive reads to this
table return different values that are unique within the
scope of the table within that agent. Such values are
assigned arbitrarily by the agent, so a manager should
make no assumption about the sequence or magnitude of
values returned."
::= { omibtransSpt 1 }
omibtransSptNextUniqueIndexEntry OBJECT-TYPE
SYNTAX OmibtransSptNextUniqueIndexEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of omibtransSptNextUniqueIndexTable."
INDEX { omibtransSptNextUniqueIndexIndex }
::= { omibtransSptNextUniqueIndexTable 1 }
OmibtransSptNextUniqueIndexEntry ::=
SEQUENCE {
omibtransSptNextUniqueIndexIndex
OBJECT IDENTIFIER,
omibtransSptNextUniqueIndex
Integer32
}
omibtransSptNextUniqueIndexIndex OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Provides a prefix indicating the type of conceptual row
to be created by a management station."
::= { omibtransSptNextUniqueIndexEntry 1 }
omibtransSptNextUniqueIndex OBJECT-TYPE
SYNTAX Integer32
Newnan Expires November 29, 1993 Page
105
Draft Translation of Internet MIBs to ISO/CCITT MIBs5/26/93
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Returns the next index to be used for creation of a
conceptual row in the indicated table.
This object typically returns a different value each
time it is read."
::= { omibtransSptNextUniqueIndexEntry 2 }
-- *******************************************************
GraphicString ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The coding and usage of this convention is the same as
for the ISO/CCITT GraphicString type except that the
string is not tagged."
REFERENCE "{ [To be provided.] }"
SYNTAX OCTET STRING
END
INTERNET DRAFT - Expires November 29, 1993
Newnan Expires November 29, 1993 Page